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(54) TiUe: METHOD AND APPARATUS FOR TESTING OBJECT-ORIENTED PROGRAMMING CONSTRUCTS 

(57) Abstract 

The invention provides methods and appara- 
tus for generating, from a source signal defining a 
subject class to be tested (40), an inspection sig- 
nal defining an inspection class (34) that has one or 
more members for (i) generating a test object as 
an instantiation of the subject class or a class de- 
rived therefrom, (ii) invoking one or more of the 
selected method members of the test object, and (iii) 
generating a reporting signal based on an outcome 
of invocation of those members. The inspection 
class, as defined by the inspection signal, can in- 
clude one or more method members (500, referred 
to as "inspection members", for testing correspond- 
ing method members of the test object (and, there- 
fore, in the subject class). So-called 'test suite mem- 
bers" (50a-50e), that are also denned as part of the 
inspection class, exercise the inspection members. 
The invention also provides methods and apparatus 
for responding to an inspection signal to create an 
inspection object instantiating the inspection class. 
Members of the inspection object are invoked to cre- 
ate the test object (80), to invoke method members 
thereof and to generate a signal reporting an effect 
of such invocation. The test object members can be 
invoked by corresponding inspection members of the 
inspection class, which in turn can be invoked by test 
suite members of the inspection class. 
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METHOD AND APPARATUS FOR TESTING OBJECT-ORIENTED 
PROGRAMMING CONSTRUCTS 

Reservation of Copyright 

A portion of the disclosure of this patent document contains material which is subject 
to copyright protection. The copyright owner has no objection to facsimile reproduction by 
anyone of the patent document or the patent disclosure, as it appears in the Patent and 
Trademark Office patent file or records, but otherwise reserves all copyright rights 
whatsoever. 

BACKGROUND OF THE INVENTION 

The invention described herein pertains to digital data processing and, more 
particularly, to methods and apparatus for testing object-oriented programming constructs. 

There are many competing factors determining how an organization tests its software. 
In the commercial environment, this includes allocating development resources, motivating 
developers to write unit tests, and maintaining those tests over the lifetime of the product. 
The central problem is focusing limited development resources on the unique aspects of unit 
tests, minimizing the overhead of creating test environments and packaging. Secondary 
factors include choosing which techniques (state-based, boundary analysis, etc.) are 
applicable to validate each production unit. 

Traditional unit testing validates the function points within a software product to 
verify the correctness of its operation. Often, the strategy is to write a dedicated test program 
for each unit, requiring separate test control and execution, set up of the test environment, and 
production of output to describe the execution of the test, as shown in FIGURE 1. 

Implementing this strategy is often informal and ad hoc. Frequently unit testing is 
abandoned because of the difficulty of this approach. When a developer determines that 
some code does need unit testing, he will create his own test harness, writing code to set up 
the test environment, run the test case, output the results and shutdown the test environment. 
The developer is concerned about all support issues, such as memory management, output 
device control and formatting, and initializing and cleaning up the application-specific 
environment. The actual test code is generally a small percentage of the entire unit test. 

This practice also tends to be invasive, where conditional test code is added to the 
production code to aid in debugging. Typically this code consists of commands to output the 
value of variables, trace the execution of the code and perhaps validate the state of the 
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environment. Conditionally compiled code introduces a new dimension of complexity into 
the production code and bugs can be introduced that only appear when this conditional code 
is disabled. Thielen, No Bugs! Delivering Error-Free Code in C and C++ , Addison Wesley 
Publishing Co. (1992) notes that this is a common problem. 

5 One way to save time is to cut and paste code from previous test cases. The cut and 

paste development methodology saves time in developing the code, but it also requires that 
changes be propagated to multiple places in the test code, increasing maintenance cost. The 
amount of time which is saved by this method is typically only short term. Since the test 
code is usually not part of a developer's deliverables, code standards may not be followed 

10 and often each developer creates his or her own set of tools for managing the en\ ironment 
and tests. This makes it hard for developers to share unit test code outside of a developmen 
group, for example in quality assurance (QA) or system integration groups. Moreover, if th 
test code is not included in the source control system, it may become lost or thrown away 
when it becomes obsolete. 

15 Some development organizations, when faced with the expense of developing unit t< 

code or with the expense of maintaining an unwieldy collection of disorganized test 
programs, give up on the test effort, leaving validation to the QA group. This is particular!: 
detrimental in an object-oriented programming environment where a system test approach i 
less effective in detecting certain classes of errors than a unit test approach. 

20 Programs produced using procedural techniques are highly function oriented, where 

programs produced with object-oriented techniques have a much greater emphasis upon the 
data being manipulated. This places a different emphasis on the program's construction. 
Traditional testing techniques can be adapted to object-oriented programs, however, they ar 
not guaranteed to exercise all of the facilities that are peculiar to object-oriented 

25 programming. 

Traditional practice in industry is to continue using the procedural organization of 
unit tests for class-based production code, as shown in FIGURE 2. Since the number of 
classes in commercial applications can be quite large, the cut and paste technique is even 
more costly. Most important is the paradigm mismatch between class-based production co 
30 and procedural unit testing. 

Objects consist of both a state and a defined behavior (operations). The functional! 
of the class is defined by both the operations and the interaction between the operations am 
the state. Traditional testing techniques can eventually exercise many of these interactions 
however, this is not guaranteed. Additionally, object-oriented programming uses techniqu- 
35 such as polymorphism which are rarely found in traditional procedural programs. 
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Current research into the testing of object-oriented programs is concerned with a 
number of issues. The black-box nature of classes and objects implies that a black-box 
testing technique would be beneficial. A number of black-box approaches have been 
developed, including the module validation technique of Hoffman et al "Graph-Based Class 
5 Testing," Proceedings of the 7th Australian Software Engineering Conference . ASWEC 
(1993) and "Graph-Based Module Testing," Proceedings of the 16th Australian Computer 
Science Conference, pp. 479 - 487, Australian Computer Science Communications, 
Queensland University of Technology, and the ASTOOT suite of tools by Frankl et al, 
"Testing Object-Oriented Programs," Proceedings of the 8th Pac ific Northwest Conference 
10 on Softwar e Qual ity , pp. 309 - 324 (1990). Both of these techniques concentrate upon the 
modular nature of object oriented programs. However Fielder, "Object-Oriented Unit 
Testing," Hewlett-Packard Journal, pp. 69 74, April (1 989) notes that a more adequate testing 
technique can be gained by combining black-box testing with the use of a whitebox coverage 
measure. 

15 In view of the foregoing, an object of the invention is to provide improved methods 

and apparatus for testing object-oriented programming constructs. More particularly, an 
object is to provide such methods and apparatus for testing classes in object-oriented 
programs and libraries. 

A related object is to provide such methods and apparatus for testing all members of a 
20 class and exercising each member over a full range of expected runtime parameters. 

Still another object is to provide such methods and apparatus for implementation in a 
wide range of digital data processing operating environments. 

SUMMARY OF THE INVENTION 

The invention provides methods and apparatus for testing object-oriented software 
25 systems and, more particularly, class constructs that provide the basis for programming and 
data structures used in those systems. 

In one broad aspect, a method according to the invention calls for generating, from a 
source signal defining a subject class to be tested, an inspection signal defining an inspection 
class that has one or more members for (i) generating a test object as an instantiation of the 
30 subject class or a class derived therefrom, (ii) invoking one or more selected method 

members of the test object, and (iii) generating a reporting signal based upon an outcome of 
invocation of those members. The source and inspection signals can be, for example, digital 
representations of source-code programming instructions of the type typically contained in 
source-code "header" files. 
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The inspection class, as defined by the inspection signal, can include one or more 
method members, referred to as "inspection members," for testing corresponding method 
members of the test object and, therefore, of the subject class. Thus, for example, the 
inspection class can include inspection members corresponding to, and taking similar 
5 arguments to, constructors and operators in the test object. Likewise, the inspection class cs 
include members corresponding to destructors in the test object. The inspection members c; 
have function names similar to those of their corresponding method members of the test 
object. 

So-called test suite members, that are also defined as part of the inspection class, car 
10 invoke for test purposes, or exercise, the inspection members. The test suite members can. 
for example, test accessor, transformer, operator or semantically unique members of the tesl 
object. The test suite members can also test the persistence of the test object, as well as 
memory leaks associated with its creation or destruction. A "run test" member can also be 
included in the inspection class in order to invoke the test suite. 

15 According to further aspects of the invention, the inspection class includes method 

members that provide common services used by the test suite members. These include 
reporting services that permit uniform generation of tracking and error reports. 

Methods as described above can further include generating, from the source signal, ; 
test signal that defines a test class. The test class may comprise the subject class, or an 

20 instantiate class derived therefrom, that inherits members of the subject class. In related 
aspects of the invention, the test class substantially duplicates pure virtual functions of the 
subject class, absent programming constructs that denote those functions as having both pui 
and virtual attributes (e.g., the "pure" and "virtual" keywords). The test class can also be 
defined to give instantiations of the inspection class access to members of the subject class, 

25 e.g., via so-called "friend" declarations. In accord with these methods, the inspection class 
includes members that create the test object as an instantiation of the test class. 

The invention provides, in yet another aspect, methodology that responds to an 
inspection signal to create an inspection object instantiating the inspection class. Members 
the inspection object are invoked to create the test object, to invoke method members there< 
30 and to generate a signal reporting an effect of such invocation. The test object members ca 
be invoked by corresponding inspection members of the inspection class, which in turn can 
be invoked by test suite members of the inspection class, as described above. 

According to other aspects of the invention, arguments are applied to the test objed 
upon instantiation of the object, (in the case of constructors) or upon invocation of the 
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selected member methods. Those arguments can, by way of example, be specified 
interactively or generated automatically. 

In a related aspect of the invention, invocation of a member function is reported by 
comparing the results of invocation of a member function with an expected value. In the case 
of disagreement, an error message can be displayed, e.g., to the user console or to an output 
file. By way of further example, the contents of the test object can be "dumped" following 
invocation. Moreover, signals indicative of the results of these and other results of 
invocation, e.g., statistics regarding the number of successful and erred member function 
calls, can be stored in data members of the inspection object. Reporting signals, such as the 
foregoing, generated in accord with the invention can be generated at selected verbosity 
levels. 

Still other aspects of the invention provide an apparatus for testing object-oriented 
software systems having functionality for carrying out the functions described above. 

These and other aspects of the invention are evident in the description that follows 
15 and in the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

A more complete understanding of the invention may be attained by reference to the 
drawings, in which: 

Figure 1 depicts a prior art strategy for unit testing of procedural code; 

20 Figure 2 depicts a prior art strategy for testing object-oriented code; 

Figure 3 depicts a preferred computing system for use in practice of the invention: 

Figure 4 depicts a production class and an inspection class according to the invention 
for testing thereof; 

Figure 5 depicts a relationship between the inspection class and test monitor and test 
25 kernel superclasses, as well as between the test subclass, the production class and the 
production superclass; 

Figure 6 depicts a test suite and inspection methods comprising an inspection class 
according to the invention; 

Figure 7 depicts illustrative states an object can enter under the persistence paradigm; 



5 



10 



WO 96/12224 



PCT/US95/06059 



-6- 

Figure 8 depicts a relationship of persistence testing methods in an inspection class 
according to the invention; 

Figure 9 depicts operation of an inspection class generator according to the inventioi 

and 

5 Figure 1 0 depicts operation of a test harness according to the invention; 

Figure 1 1 depicts a window displayed and used in a test harness according to the 
invention. 

DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENT 

FIGURE 3 depicts a preferred networked computing system for use in operation of 
10 the invention. The system includes a digital data processor 1 2. including a processor sectioi 
14, a random access memory section 16 and an input/output control section 18. The digital 
data processor 12 is connected, via input/output control section 18, to monitor 24 (including 
monitor, keyboard and pointing device) and to hard disk 22 for storage of software and data 
Digital data processor 12, as well as its sub-components 14-18 and peripherals 22 - 24. 
15 preferably comprise a conventional commercially available personal computer or work 

station adapted in accord with the teachings below for the testing of object-oriented so ft war 
As further indicated by the drawing, digital data processor 12 is connected with printer 25 
and with other other digital data processing apparatus 27A. 27B, 27C via network 26. 

Inspection Methods 

20 Reed, "Object-Oriented Design by Orthogonality," Computer Languag e, vol. l >. no 

pp. 51 - 56 (1992), discloses an object-oriented library architecture using orthogonaiit> 
Building on that architecture, methods and apparatus according to the invention utilize 
inspection methods to package test code and inspection classes package inspection method- 
Referring to FIGURE 4, a production class 30 (i.e., a class from the production cod 

25 to be tested includes three method members A (element 32a), B (element 32b), and C 

(element 32c). Method member A, by way of example, is a Boolean function that takes an 
integer argument and is prototyped, e.g., in the production class header file, as "bool A(int) 

An inspection class 34 according to the invention includes three method members 
I_Class::A (element 36a), I_Class::B (element 36b), I_Class::C (element 36c) correspondii: 
30 to like-named method members A, B and C, respectively, of production class 30. Class 34 
defined as part 38a of unit test source code stored in a conventional manner (e.g., on disk 2 
in source and header files 38 for compilation, linking, loading and execution using 
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commercially operating system tools in connection with libraries constructed in accord with 
the teachings herein. 



As shown in the drawing, method member I_Class::A takes arguments and returns 
5 values identical to those of corresponding member A. Member I_Class::A takes, as an 

additional argument, a pointer to a test object created from the production class or a test class 
derived therefrom. As further shown in the drawing, method I_Class::A includes instructions 
for invoking member A of the test object, as well as for reporting invocation, arguments to, 
and return values from that member. Thus, by way of example, where member A is declared 
10 as follows: 

bool A(Int argl); 

I Class::A can be declared as follows: 



bool 

I_CLASS::Class:: A(P_Class* Obj, 
Int argl) 

{ 

AnnounceStart( M A ,, ); 
AnnounceParameter(argl ); 

bool tstVal = Obj->A(argl); 
AnnounceRtnValue(tstVal); 
AnnounceEnd("A n ); 
retum(tstval); 

} 



// report start of test 

// report parameters that will be 

// passed to member to be tested 

// invoke member 

// report member result 

// report end of test 

// return member result 



Each of the inspection methods take the object under test as a parameter, as well as 
15 the rest of the parameters necessary for the production method, as shown in FIGURE 4. This 
not only reduces cut and paste code, but also eliminates the need for specialized test code in 
the production class that is used only during unit testing. It is much preferred to have 
instrumentation outside of production code rather than compiled in, even if the compilation is 
conditional. 

20 The inspection class methods are capable of running against code built for general 

release as well as development and unit testing. With a "dump" method enabled during 
development, unit tests facilitated by the inspection class provide a white-box testing 
environment, allowing the developer to be most effective in determining corrective actions 
for failed tests. Black-box test techniques are in effect when the dump method is disabled for 
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general release. Unit tests in this form can be run as acceptance tests by QA prior to produa 
level tests. The dump method is a member method preferably included in all production 
classes that prints, or "dumps," state information of the contained member data and objects. 

Inspection Classes 

5 From the inspection methods, an "inspection class" providing a non-invasive 

instrumented interface is constructed. This interface includes an inspection method for each 
public and protected member in the production class. The inspection class interface is 
analogous to the production class interface; thus, developers need to learn very little in ordei 
to construct unit tests. 

10 The inspection class 34 and its inspection methods 36a - 36c are can be generated by 

parsing the production header files and constructing inspection class headers and source file 
from the production code header files. 

The Test Subclass 

Referring to FIGURE 5, there is shown a test subclass 40 that derives from 
15 production class 30. Thus, test subclass 40 includes method members 42a, 42b, 42c 

corresponding to method members 32a, 32b, 32c, respectively of the production class 30. 

Definition of a test subclass 40 according to the invention solves problems associate 
with accessing protected production methods or instantiating abstract classes. Since the tesi 
subclass 40 is derived from the production class 30, it has access to the protected methods o 
20 its parent. Access to such protected methods by the inspection class 34 is granted by 

inclusion, in the test subclass definition, of statements declaring the inspection class as a 
"friend" (in C++ terminology). This insures that testing is completely non-invasive. For 
those classes which do not need a test class, the test class 40 is replaced with an alias to the 
actual production class 30. 

25 The test subclass also provides a location for the implementation of the pure virtual 

functions of the production class. Typically, those functions are implemented by stubbed-o 
code. 

As further shown in FIGURE 5, the production class derives from a production 
superclass 44, while the inspection class 34 derives from a test monitor superclass class 46 
30 which, in turn, derives from a test kernel superclass 48. The test monitor class 46 defines 
data members for storing results of each unit test. The test kernel class 48 defines method 
members for uniform reporting of unit test results, status and coverage. 
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Given a set of inspection methods 36a - 36c grouped into an inspection class 34, 
common services of test output and test environment maintenance are provided by test 
instrumentation base classes 46, 48. The kernel test class 48 allows infrastructure objects to 
be tested in isolation. It provides services for output verbosity control, output formatting, 
5 memory management leak detection and reporting, expression checking, and reporting of 
errors encountered. 

The monitor test class 46, derived from the kernel test class 48, provides additional 
services to application classes such as application environment initialization and cleanup, test 
case setup and cleanup, gross level coverage measurement and reporting, and unit test 
10 execution. 

Organization of Test Suites 

Source code and header files providing definitions of the inspection class 34 and test 
subclass 40 are preferably generated automatically from a header file defining the production 
class. This results in a reduction in the amount of code the developer needs to write in order 
15 to insure thorough testing of the production class. This section examines the definition and 
interrelationship of unit tests within the inspection class. 

Unit tests must achieve a certain minimum standard of coverage. This is ensured by 
dividing the set of production class methods, e.g., 32a - 32c, into groups according to 
behavior and testing technique, taking into account dependencies between various groups. 
20 For example, all methods depend on the constructor methods. Referring to FIGURE 6, 
production class 30 methods are tested by the following groups of inspection class tests: 
memory lifecycle 50a, persistence lifecycle 50b, get and set attributes 50c, operator members 
50d, and semantics 50e. 

Memory lifecycle tests 50a exercise those methods of the production class which 
25 affect the life of the corresponding object in memory. These include the constructors, copy 
constructors, destructor and assignment methods of the production class. Generally, errors 
which occur in the lifecycle are memory leaks and improper initialization. Lifecycle tests 
involve creating test objects (based on the production class, or the test class derived 
therefrom) using each constructor in the production class 30, assigning objects (e.g., in the 
30 case of copy constructors), and deleting the test objects from memory. Checks are then made 
for leftover allocated memory. 

Persistence lifecycle tests 50b exercise those objects that are stored in a database (e.g., 
on disk 22) for later retrieval or storage across invocations of the product. A state-based 
testing approach is used for persistent methods. The states defined in the memory and 
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persistence lifecycles are so regular that a majority of the test cases in these sections can be 
predefined and therefore implemented by inspection class generator apparatus and methods 
according to the invention, thereby reducing developer effort. 

Get and set tests 50c exercise those methods which allow the access to and setting oi 
5 value-based attributes of the production class. Testing assures that the values can be 

accessed, and that ancillary properties such as "read-only" are complied with. A state-based 
testing approach is preferably used for this group. 

Operator tests exercise 50d those methods of the production class that perform 
comparison, arithmetic, logical operations and others. Operator testing is functional in natu: 
10 and relies on techniques such as equivalence class partitioning and boundary value analysis- 
Semantics tests exercise 50e those members of the production class whose behavior 
that makes the object unique. Because of that uniqueness the inspection class generator 
apparatus and methods do not attempt to generate code for exercising those members but, 
rather, they merely generate method declarations (and comments) to remind the developer t( 
15 draft his or her own test code. 

Test Suite Packaging 

An inspection class generator generatesindividual tests, along with inspection 
methods 50f providing the instrumented interface. These inspection methods are, themselvt 
packaged into "test suites" As a consequence of the resulting uniform organization of all 
20 inspection classes, the set of unit test suites can be executed in a uniform manner. 

A standard entry point, e.g., referred to as "testmain(), M in testing code for 
constructing an instance of the inspection class and invoking a method member, e.g., 
"testrunO " ^at exercises the members of the test suite. The implementation of testmain() i 
a nonclass function which is automatically generated by the inspection class generator. 

25 Persistence Testing 

The following sections examine the application of state-based testing to the 
persistence of objects. State-based testing and its applicability are described. An example i 
a multi-state object is shown. Some additional testing problems due to the specific 
persistence approach are also discussed. 

30 State Based Testing 

Of the various methods considered in developing test cases, state-based testing was 
the most applicable to persistence. State-based testing was developed at the University of 
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Durham to address some of the problems in adapting testing techniques to object-oriented 
programming, and is described in Turner el al t "The Testing of Object-Oriented Programs," 
Technical Report TR- 13/92 . University of Durham, England (1992). 

An object's behavior is defined by the code within its operations. Events and 
5 situations occur that have to be communicated to the other operations of the object. This 
communication is usually performed by storing specific values within the attributes of the 
class. State-based testing models these interactions as a finite-state-automata which is then 
used to predict the response of each operation to a particular state. 

Test cases are generated to validate that at no point in an object' s lifetime can it be 
10 placed into an undefined or incorrect state. All operations are validated for the state changes 
which they are defined for, operations can also be validated for their robustness when faced 
with an illegal state situation. 

An example deals with persistent classes. Persistence is implemented by a root 
persistent class from which all persistent objects are derived. The persistence paradigm 
15 requires six states that an object can enter: 

New - the object was created and exists in memory only 

Saved - the object exists in the database and not in memory 

Open for Read/Write - the object exists (and is identical) in memory and the database and the 
client may save changes to the object 

20 Modified Read/Write - the object exists in memory and the database with different values and 
the client may make changes to the object 

Open for Read Only - the object exists (and is identical) in memory and the database and the 
client may not make changes to the object 

Deleted - the object does not exist in memory or the database 

25 FIGURE 7 illustrates some of the legal transitions between these states. Thus, for 

example, an object may transition from a New state 52a, or a Modified Read/Write state 52e r 
into a Saved state 52b. From that state 52b, an object may transition to an Open Read Only 
52c or an Open Read/Write state 52d, whence it may transition to a Deleted state 52f. An 
object may also transition into a Deleted state from the Modified Read/Write state 52e. 

30 Since the root persistent class is inherited by all persistent classes, these classes share 

the above states 52a - 52f, although the implementation is made specific to each class by 
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providing some of the persistence code in a code template that is instantiated for each class. 
The test cases for these objects should also be similar, with minor changes from class to clas 
Because the persistence functions can be critical to the operation of an object-oriented 
product, it is not sufficient to test the functions solely at the root level. 

The situation of shared critical functionality leads to another testing problem. Given 
the similarity of the tests, interest in rewriting the same test cases over and over for the 
persistent classes is likely to be low. 

As illustrated in FIGURE 8, the inspection class generator conditionally generates 
the persistence lifecycle tests 50b to include standard persistence state tests 54. The 
condition which causes this generation is if the inspection class generator detects that the 
production class is persistent. 

This solution allows each production class 30 to be tested with a minimum set of tes 
cases assuring a certain level of test coverage. The developer must supply a test setup routir 
56 specific to the class under test. This is a short and well-defined piece of code, and the 
inspection class generator supplies a function body skeleton. Then the developer can code 
additional test cases as deemed necessary to the particulars of the class 30. 

An additional advantage to this approach is that it provides a single point for the 
maintenance of the test cases. If the persistence application program interface (API ) is 
modified, the amount of test code to be changed is minimized. 

This does not appear to be an unique situation; it seems likely that there will be.oihe 
cases where a whole model - an API and series of states - is shared among many classes. 
Using state-based testing provides a significant savings here by allowing the development o 
a template of standard cases which are shared by the inspection classes. It should be noted 
that this approach not only demonstrates the correctness of the code under test but also 
demonstrates the correct integration of the shared production code template. 

Inspection Code Generator 

FIGURE 9 illustrates operation of an inspection code generator (ICG) 58 according 
to the invention. The generator 58 accepts, as input, a header file 60 defining the productio: 
class 30 be tested. The generator 58 generates, in accord with the teachings herein, a heade 
file 62a and a source code file 62b defining the inspection class 34 and the test class 40 for 
testing the production class 30. 

In the illustrated embodiment, files 60 and 62a - 62b contain C++ programming 
statements in source-code format. The header file 62a contains function declarations or 
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prototypes corresponding to those in the file 62b. Those skilled in the art will appreciate that 
the teachings herein are likewise applicable to other programming languages including 
object-oriented constructs, e.g., Turbo Pascal. Likewise, it will be appreciated that the 
information in the files may be input or output in other formats (e.g., object code) known in 
the art. 

The statements contained in files 62a, 62b define the inspection class 34 to include 
members that (i) generate a test object as an instantiation of the test class, (ii) invoke selected 
method members of the test object, and (iii) generate a reporting signal based upon an 
outcome of invocation of those members. 

The inspection class 34 particularly includes inspection members (also referred to as 
"inspection" members) that test corresponding method members of the test object. Thus, for 
example, the inspection class 34 includes inspection members, e.g., 36a - 36c, corresponding 
to, and taking similar arguments to, constructors, destructors, operators and other method 
members, e.g., 32a - 32c, in the test object. To facilitate testing, the inspection members 
(apart from constructors and destructors) have function names similar to those of the 
corresponding method members of the test object that they test. 

The inspection class 34 defined by files 62a, 62b also includes test suite members that 
invoke or exercise the inspection members for test purposes. The test suite members 50a - 
50e that test accessor, transformer, operator or semantically unique members of the test 
object, as well as the persistence of the test object and memory leaks associated with its 
creation or destruction. A "test main" member 50f invokes the test suite. The inspection 
class provides, via inheritance from the test monitor class and test kernel class 48, members 
50f that permit uniform tracking and reporting of test coverage and errors, 

The statements in files 62a, 62b also define a test class 40 that derives from the 
production class 30 and, therefore, inherits members, e.g., 32a - 32c, therefrom. The test 
class 40 duplicates pure virtual functions of the subject class 30, absent programming 
constructs that denote those functions as having both pure and virtual attributes (e.g., the 
"pure" and "virtual" keywords). The test class 40 affords the inspection class members, e.g., 
36a - 36c, access to members, e.g., 32a - 32c, of the subject class, e.g., via C++ friend 
declarations. 

Generation of the inspection class header and source files 62a, 62b by the ICG 58 may 
be understood by reference to the Appendix A, providing a listing of a sample production 
class header file 60 named "utg.hh"; Appendix B, providing a listing of a sample inspection 
class header file 62a named "i_utg.hh" that is generated by the ICG 58 from file 60; and, 
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Appendix C, providing a listing of a sample inspection class code file 62b named "i_utg.cpp 
that is also generated by the ICG 58 from file 60. 

The items listed below refer to the annotations made on the listings provided by 
Appendices A - C. In the description of each item, reference is made to the three classes 
5 involved in the unit test: 

1 . The source production class 30, which may be an abstract or concrete class. 

2. The test class 40. This is a generated class which is derived from the production clas; 
to provide access to the public and protected member functions of the production class, and 
declarations for implementations of virtual functions declared pure virtual in the production 

10 class. 

3. The inspection class 34. This class performs tests on instances of the test class 40. 

Where dictated by context, references in the explanatory items below to the 
"production class" shall be interpreted as references to the corresponding file 60, and 
references to the "inspection class" and the "test class" shall be interpreted references to the 
15 files 62a, 62b. 

Explanation of Annotations to Production Class 
File 60 Listing of Appendix A 

1. Copyright notice comment. 

2. Include file guards are based on format <filename>HR 

20 3. Filename utg.hh becomes "i_utg.hh" for inspection class header file 62a. The 
inspection class source file 62b becomes "i_utg.cpp ." 

4. All #include's lines in production class file 60 are ignored. 

5. Class comment is not copied to the inspection class files 62a, 62b. 

6. The ILIBRARY keyword value (ER) is used for generating the inspection class file 
25 62a, 62b comments. 

7. The INAME keyword value (utg) is used for generating the inspection class file 62;= 
62b comment. 

8. The name of the production class (utg) to be tested. The EXPORT keyword may 
appear before the declaration of the class. 
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9. The start of the public member functions (and member data) are signaled by the 
"public" keyword. The keywords "protected" or "private," or the close of the class 
declaration "} ;" end the public section. C++ permits multiple public sections within a class 
declaration. 

5 10. ICG 58 ignores enumerations, indicated by the keyword "enum." 

1 1 . Constructors. C++ permits more than one per class. C++ also permits constructors to 
be overloaded. 

12. Copy Constructor. If provided, there is only one. A copy constructor has as its first 
required argument a reference (&) to an instance of this class (usually declared const). In a 

10 preferred embodiment, there is a second, optional argument, a memory manager defaulted to 
NULL. All classes must have one, but they can be private and unimplemented. 

13. Destructor. The definition of most classes include a public destructor. 

14. Assignment operator. All classes must have one, however, they can be declared 
private and not implemented. 

15 15. Conversion operator. This operator, also known as cast, is provided in addition to the 
operators defined by C++. This operator returns an object of the type identified in the 
operator statement (e.g., dtULong). Also notice, this member function is const, which is not 
used in generating the signature of the inspection member function. 

16. The addition assignment operator returns a reference to an object of this class type. 

20 17. A static member function (sometimes called a class function) returning an erStatus 
object. A pointer to a production object is an output parameter. The static specifier is not 
included in the corresponding statement in the inspection class files 62a, 62b. 

18. Public member data is ignored when generating the inspection class files 62a, 62b. 

19. The start of the protected member functions (and member data) is signaled by the 
25 "protected" keyword. The keywords "public" or "private," or the close of the class 

declaration "};" ends the protected section. C++ permits multiple protected sections within a 
class declaration. 

20. An overloaded index operator implemented as a const member function. Again, note 
that the const is ignored for the generated inspection function. 
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21. A pure virtual constant member function. This function signature is used to generate 
private virtual function declaration in the test class. This is done in order to satisfy the 
compiler that no attempt is being made to instantiate an abstract class. The pure (=0) specifu 
is not included in the test class declared in the inspection class header, but the const specifie 

5 must be preserved for this one case. No implementation is generated. 

22. A virtual set member function with a default argument. The default argument is usee 
when generating the function signature of the inspection function. In this example, there 
exists a constant pointer to a constant object, with a default value of NULL. 

23. The OPLDEBUG constant dump member function is defined for all objects. This 
10 member function is not duplicated in the generated inspection class. 

24. Protected member data is ignored when generating the inspection class. 

25. The start of the private member functions (and member data) are signaled by the 
private: keyword. The keywords public: or protected:, or the close of the class declaration } 
ends the private section. Multiple private sections are possible within a class declaration. 

15 26. Private member functions and data are ignored when generating the inspection class 
files 62a, 62b. 

27. Nonclass function appearing in the header for the production class. These do not 
appear often, and are usually a specialized function used by the production class. 

28. Global nonclass operator appearing after the production class declaration. Similar ir 
20 use to nonclass functions. 

29. Close of the include file guards. 

Explanation of Annotations to Inspection Class 
Header File 62q Listing qJ Appendix B 

1 . Copyright notice comment copied from production class. 

25 2. Include file guards are generated based on inspection class header filename (minus 
extension). 

3. File name is i_utg.hh. The rules used to generate the filename are the same as those 
for the class. The name must be unique (in the output directory) so that existing inspection 
classes are not overwritten. An optional parameter on the command line specifies the name 
30 the output filename. 
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4. The inspection base class declaration is included by the statement ^include "idt- 
test.hh" 

5. The production class header is included by the statement #include "utg.hh". 

6. Inspection class comment. The IAUTHOR, ! REVIEWER, and ! RE VIE W_D ATE 

5 keywords and values are defaulted from a template (values from production class header are 
not used). 

7. The inspection class comment keyword 1LIBRARY value adds an "I J" prefix to the 
value from the production class comment (I_ER). 

8. The inspection class comment keyword !NAME value adds a prefix to the name 
10 of the class (i_utg). 

9. The inspection class generator 58 places a comment indicating that this file 62a is 
generated by a tool, to wit, the generator 58. The comment is entered in the !TEXT section of 
the class comment, and includes a date, the name of the tool, and the version of the tool. 

10. The test class declaration publicly inherits from its production class to provide access 
15 to protected member functions. The test class name has "s_" prepended to the production 

class name. All member functions are declared in the "public:" section of the test class. 

1 1 The test class declares the inspection class as a "friend." This allows the inspection 
class to invoke protected (and public) member functions on the production class. 

12. Test class constructors and copy constructors are declared and implemented inline to 
20 replicate the public and protected interface on the production class. The private interface o\ 

the production class is not used. 

13. Declaration to satisfy the compiler for a pure virtual member function declared in the 
production class. The declaration has lost its pure specifier (=0), but not its const function 
specifier. Also, the virtual specifier from the production class is also not needed (if it is easy 

25 to strip off, do it, otherwise the virtual specifier can stay). A comment is generated as an 

indication to the unit test developer that an inline implementation may be required (if linking 
causes this function to be unresolved, i.e., it is being called by some object). 

14. An enum named FUNCS contains entries for each inspection function and a final 
entry named TOTAL FUNCS. Each entry is composed of a prefix of f_ followed by the 

30 name of the inspection function. Where functions are overloaded (e.g., multiple constructors) 
it is necessary to append a number indicating which of the functions this enumeration applies. 
This enum is used for calculating base coverage analysis. 
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1 5. An integer array the size of TOTAL_FUNCS is used for based coverage analysis. Th 
name of this dtlnt array is coverage. 

1 6. The inspection class publicly inherits from the base test class idtTest. 

17. The "public:" keyword is used to make all inspection class member functions 
5 available. 

1 8. The inspection class itself requires a constructor and destructor. There is a difference 
between inspection class member functions and inspection member functions for the class 
under test. The member functions of the inspection class are needed to provide the behavior 
for the unit test as defined by idtTest and coding standards. The inspection member functior 

10 are those functions needed to test the production class member functions. 

19. The inspection test suite functions are more inspection class member functions. The; 
implement the pure virtual functions defined in idtTest. These functions are invoked from tl 
runTest member function of idtTest. The test functions are: t LifeCycle, tOperators, 
tJSemantics, tSetQrys, and t_Persist. The qryCoverage member function is used to provid< 

15 the coverage data for the base coverage analysis. 

20. For each public or protected constructor provided by the production class there is a 
"newlnstance" inspection member function. The newlnstance member function takes the 
same arguments as the production class constructor and returns a pointer to an instance of tl 
test class. 

20 21. If the production class has a public or protected copy constructor, then a copylnstan 
member function is generated. This inspection member function takes as the first argument 
pointer to an instance of the test class, followed by the arguments of the production class' 
copy constructor (usually the memory manager). A pointer to an instance of the test class is 
returned. NOTE: the second parameter is optional and has a default value; this mirrors the 

25 production class copy constructor. 

22. If there is a public or protected destructor declared on the production class, a 
deletelnstance inspection member function is generated. This inspection function takes one 
parameter, a pointer to an instance of the test class. There is no value returned (dtVoid). 

23. Operator inspection member function naming. All operator functions must be mapj: 
30 into a function name of the form "oper_<operator-name>. n Above each declaration is a 

comment indicating its original name in the production class. In the annotations on Appen 
B, the term "ARM" refers to the Annotated C++ Reference Manual, authored hv M. A. Ell 

and B, Stroustmp f Addison- Wesley. 199Q). 
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24. Assignment operator inspection function. The first argument, as a general rule for all 
member functions, is a pointer to an instance of the test class, followed by the arguments 
from the production class assignment operator. The return type is modified to return a test 
class (s_utg&) instead of a production class (utg&). The suggested name for this operator is 

5 oper_equal. 

25. The conversion operator must return an object of the same type as the conversion. 
Since a conversion operator itself has no arguments, the only argument becomes a pointer to 
an instance of the test class. The suggested naming for conversion operators is 
oper_<con version- ty pe> . 

10 26. The addition assignment operator modifies the return type to a test class, and inserts a 
pointer to an instance of the test class, followed by the arguments defined by the production 
class. The suggested naming for this operator is oper_plusequal. 

27. The static production member function has lost its static specifier in the inspection 
class. Also, production class parameter type has been replaced with the test class. 

15 28. The index operator follows the same general rules as described for the assignment 
operator. The suggested name is operindex. 

29. The virtual setID member function contains a default argument, which is a constant 
pointer to a constant object. The virtual specifier from the production class is not needed on 
the inspection class (if it is easy to strip off then do it otherwise the virtual specifier can 

20 stay). A pointer to an instance of the test class is inserted as the first argument, with the 
production class arguments following; including the default argument (=(const dtChar* 
const) NULL). 

30. The start of the "private" section, and the end of the "public" section. 

3 1 . Declaration of the inspection class* copy constructor and assignment operator member 
25 functions. These are not implemented in the inspection class source file 62b. 

32. Nonclass functions are declared outside of the inspection class. Their return type and 
arguments are preserved (a pointer to an idtTest object is inserted as the first argument, and 
production class types are modified to test class types). The name is changed so it does not 
conflict with the production header nonclass function name. A suggested naming scheme for 

30 nonclass functions is <inspection-class-name>_<nonclass-function-name>. For example, 
export becomes i_utg_export. 
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33. Global operators are declared outside of the inspection class. Return type and 
arguments are preserved (a pointer to an idtTest object is inserted as the first argument, and 
production class types are modified to test class types). The name is changed so it cannot 
conflict with the production global operator name. A suggested naming scheme is 

5 <inspection-class-name>_oper_<operator-name>. Therefore, the global production operator 
becomes i_utg_oper_plus in the inspection header. 

34, The end of the include file guard. 

Explanation of Annotations to Inspection Class 
Source File 62b Listing of Appendix C 

10 1. Copyright notice comment. 

2. Name of this file. Follows naming rule identified in item 3 of the prior section. 

3. Include the inspection class header. 

4. Insert the TESTRUNdeclare macro text. Substitute in the name of the inspection cla: 
(Lutg). 

15 5. Insert the text for the comments, TESTRUN, and testname. substituting the name of 
the inspection class. 

6. Class description comment, mostly a template with 3 substitutions. 

7. Prefix the name of the library with an 

8. Prefix the name of the class with an "i J\ 

20 9. Insert a string describing the date and version of the inspection class generator whicl 
generated this file. 

10. Insert the class constructor with the coverage array initialization code, substituting tl 
name of the inspection class. 

1 1 . Destructor, leave empty, and substitute the name of the inspection class. 

25 12. Lifecycle testing comment, insert as is. 

13. Lifecycle testing initialization, insert as is, substituting the inspection class 
name. 
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14. Invoke newlnstance using mm, substitute test class name. In further embodiments, a 
constructor/destructor test (TLIFE_START through TLIFE_END) can be generated for each 
existing production class constructor. Likewise, they may include argument types in where 
/♦PARAMETERS,*/ currently appears. 

15. Copy as is. 

1 6. Invoke newlnstance using mm, substitute test class name. 

1 7. Invoke copylnstance using mm2, substitute test class name. In further embodiments, 
a constructor/destructor test (TLIFESTART through TLIFE END) can be generated for 
each constructor/copy constructor combination. Likewise, they may include argument types 
in where /* PARAMETERS,*/ currently appears. 

18. Copy as is. 

19. Invoke newlnstance using mm, substitute test class name. 

20. Invoke newlnstance using mm2, substitute test class name. In further embodiments, a 
constructor/destructor test (TLIFE_START through TLIFE_END) can be generated for each 
constructor/assignment operator combination. Likewise, they may include argument types in 
where /*PARAMETERS,*/ currently appears. 

2 1 . Copy as is. 

22. Three invocations of newlnstance using mm, mm2, and mm. Substitute test class 
name. 

23. Copy as is. 

24. Invoke newlnstance using mm, substitute test class name. 

25. Copy as is. 

26. Operators testing comment, copy as is. 

27. Operators testing body skeleton, substitute inspection class name for scope name 
(i_utg : : t_Operators). 

28. Comment and body for set and query tests. Same rules as requirement 27. 

29. Semantics testing comments and body. Same rules as requirement 27. 
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30. Persistence testing comments and body. Same rules as requirement 27. In this case, 
the class is not persistent, so that no persistence testing is generated. Such testing is shown in 
the example below for the persistent class BasResc (see Appendix F and the accompanying 
text, infra). 

5 31. Return coverage information. Copy as is, substituting inspection class name for scope 

32. Comment for constructors (newlnstance) for test class. Copy as is. 

33. Generate function signature using production class constructor signature, substituting 
test class name (s_utg) for production class name (utg). using inspection class name for scope 
(i_utg). Applies to all inspection functions. 

10 34. Generate coverage counter code (applies to all inspection functions). Use the scheme 
outlined in requirements 14 and 15 of section 3. The member function name text is used to 
substitute into coverage index text. 

35. All inspection functions have an announceMethod Start call, substituting a unique 
name (requirement 34) based on the function as the argument ("newlnstance T)- 

15 36. Invoke the corresponding constructor on the test class, substituting the test class name 
for the production class name. 

37. All inspection functions have an announceMethodEnd call, following the rules 
outlined in requirement 35. 

38. All newlnstance inspection functions return a pointer to an instance of the test class 

20 39. Invoke the test class copy constructor in copylnstance. dereference alnstance. 
Substitute test class name where appropriate. 

40. The deletelnstance member function must generate a delete statement. 

4 1 . Generate function signatures for other inspection functions using same rules as 
out 1 ined i n requirement 33. 

25 42. Invoke the corresponding member function on the test class. 

43. If the inspection function returns a value, generate the return statement using either 
the alnstance pointer or the testVal variable. 



44. Another version of requirement 42, this time the corresponding test class member 
function invoked returns an object. Declare testVal of the correct type. 
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45. Another version of requirement 43, this time a testVal is being returned. 

46. Nonclass functions have a pointer to an idtTest passed in as the first argument. This 
pointer is used for invoking the announceXxxx member functions. This is done because 
nonclass functions are not member functions on an inspection object (an inspection object is- 

5 a idtTest object). 

Generation of the inspection class header and source files 62a, 62b by the ICG 58 may 
be further understood by reference to the Appendix D, providing a listing of sample 
production class header 60 named "basresc.hh"; Appendix E, providing a listing of a sample 
inspection class header file 62a named "i_basres.hh" that is generated by the ICG 58 from the 
10 file basresc.hh; and, Appendix F, providing a listing of a sample inspection class code file 
62b named i_basres.cc that is also generated by the ICG 58 from the file basresc.hh. 

The code generation operations revealed Appendices D - F include support for basic 
persistence testing of a persistable (or persistent) object is the body using the th t_persist(r 
function and two additional support member functions for setting up valid user keys and 
15 persistent objects. 

The items listed below refer to the annotations made on the listings in Appendices D - 
F. In the description of each item, reference is made to the three classes involved in the unit 
test: 

1 . The source production class 30, which is a concrete persistent class. 

20 2. The test class 40. This is a generated typedef which provides access to the public 
member functions of the production persistent class. 

3. The inspection class 34. This class performs tests on instances of the test class 40. 

As above, where dictated by context, references in the explanatory items below to the 
"production class," the "inspection class" and the 4fc test class" shall be interpreted references 
25 to the corresponding files 60, 62a, 62b. 

Explanation of Annotations to Production Class 
File 60 Listing n f Appendix D 

1 . User Key class name. A user key is a class that contains text which is the name of a 
persistent object. This can be obtained from scanning the second parameter type of the 
30 openForChange(), openForReview(), and saveAs() member functions. In an alternate 
embodiment, a hint as to the icg is obtained from the production class developer via a 
IUSERKEY keyword. 
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Explanation of Annotations to Inspection Class 
Header File 62a Listing of Appendix E 

1 . User key setup member function signature. The setupUKs() member function takes 
four arguments: three user keys and a memory manager pointer. Copied as is except where 

5 noted in 2. 

2. User key class name is used for each of the three user key arguments. This is the onl; 
item that needs to be substituted in this function signature. 

3. persistent object setup member function signature. Takes two arguments: test class 
pointer and a memory manager pointer. Copied as is except where noted in 4. 

10 4. Test class name is the only item that must be substituted. 

Explanation of Annotations to Inspection Class 
Source File 62b Listing of Appendix F 

1 . Define the test class name. This must be substituted using the generated test class 
name. 

15 2. Define the object reference template parameter. The value that must be substituted i: 
the name of the production class within the angle brackets (oObjRef<ProdClass>). 

3. Copy other definitions as is, only STDGIT_PRODUCTION should not be com- 
mented. 

4. Declare three User Key objects. Substitute the class name of the user key. 

20 5. Declare other test objects. This includes three persistent instances, a security conic v 
and a commented kind reference. 

6. Declare a kind reference with its template parameters. Declares a variable named "k 
of the appropriate kind reference. A kind reference is a templated class, and this item is 
calling out the production class name that must be substituted in the first template paramet< 

25 oObjRef (which is itself a templated class). Similar to item 2 in this section. 

7. The second kind reference template parameter must be substituted with the user ke; 
class name. 

8. The rest of the t_persist member function body is copied as is. Note the inclusion c 
the templated persistence test text. 
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9. The qryCoverage member function, which is currently being generated. 

10. The user key setup member function body, setupUKs(). This is copied as is, except 
where noted in 1 1 . 

1 1 . User key arguments for setupUKs() requires substitution of the user key class name. 

5 12. The persistent object setup member function body, setupObj(). This is copied as is, 
except where noted in 13. 

13. Test class pointer argument for setupObj() requires substitution of the test class name. 

Unit Test Harness 

With continued reference to FIGURE 9, the inspection class source file 62b 
10 generated by ICG 58 is compiled, linked and loaded (see element 64), along with production 
class header and source files 60, 68, as well as library files containing the test monitor class 
definitions 70 and the test kernel class definitions 72. Compiling, linking and loading is 
performed in a conventional manner, e.g., using a C++ compiler sold by Microsoft 
Corporation. The resulting file 66 containing executable code for the unit test harness is 
15 executed on digital data processor 12 to reconfigure that processor as the unit test harness. 

FIGURE 10 depicts operation of the unit test harness 74. Particularly, testmain() 
routine 76 creates an inspection object 78 as an instantiation of the inspection class 34 
defined in files 62a and 62b. Testmain() also invokes testrun(). The testrun() method 79 of 
the inspection object invokes test suite members 50a - 50e of the inspection object, each of 
20 which (i) creates a test object 80 instantiating the test class 40 (defined in file 62b), (ii) 

invokes a members of the test class, e.g., 42a, via corresponding inspection members, e.g., 
36a, of the inspection class, and (iii) utilizes reporting members 82 of the inspection object 78 
to report results of the invocation of the test class members. Reports can be generated to 
printer 25, to monitor 24, to a file on disk drive 22, or in other media as known in the art. 

25 As illustrated, the test harness 74 accepts arguments, e.g., from the user, for 

application to the test object upon or upon invocation of the selected member methods, e.g., 
42a. Such arguments can, alternatively, be generated automatically be the test harness 74, 

Reports generated by members 82 of the inspection object include those resulting 
from comparing the results of invocation of the test object member, e.g., 42a, with expected 
30 result values. In the case of disagreement, report members 82 cause an error message to be 
displayed, e.g., to the printer, monitor or a disk file. Report members 82 also permit the data 
members of the test object 80 to be "dumped" following invocation. The report members 82 
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store data reflecting errors that occur during invocation of the test object members, e.g., 42a, 
and coverage of the testing (i.e., which test object members are tested). 

Unit Test Classes 

idtkrnl 

Report member 82 includes macros inherited from class idtKrnl 48 (Figure 5) 
providing unit test output. Significant among these are two that provide for error checking 
and a third that gives the developer the ability to output their own status message: 

checkExpr{ expression, testname ) - Announces an error if the expression evaluates to 
FALSE, returning the value of the expression. 

checkMemMgr( memoryMgr, testname ) - Announces an error if the Memory Manager 
detects a memory leak. Returns TRUE if no leak was detected, FALSE when there is a leak. 

announceStatus{ message, testname ) - Announces the message in standard unit test format. 

These macros automatically report the standard output information such as current fi] 
and line. The report members 82 also include specific announcement members inherited fror 
class idtKrnl 48, including announceObjectQ, which dumps the contents of the object to the 
output stream. 

idtKrnl 48 also provides other announcement methods: 

announce MethodStart( methodname ) - Reports the start of the named method 

announce MethodEnd{ methodname ) - Reports the end of the named method 

announceParameter{pdXBm^XtxOh) ) - Dumps the contents of the object, under the label 
"Parameter" 

announceRetVal{ returnObj ) - Dumps the contents of the object, under the label "Return 
Value" 

idtTest 

The superclass idtTest 46 also provides to inspection object 78 mechanisms for 
executing unit tests and monitoring test coverage. In this regard, the inspection object inherii 
from idtTest 46 the following macros to standardize the start and end of the test suite metho< 
50a - 50e (also referred to as t_* methods): 
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T_INIT( methodname ) - Initialize a t_* method, setting up a test memory manager, mm 

T_CLEANUP( methodname ) - Clean up a t_* method, checking the memory manager for 
leaks. 

TESTJSTART( testname ) -* Start a test scenario 

5 TESTEND - End a test scenario; announces whether the scenario passed or failed. 

TEST( testname, expression ) - A combination of TEST_START() and TEST END for tests 
which consist of a single expression to check. 

checkExceptf expression, id, testname) - Verify that evaluating the expression throws an 
exception with the id indicated. CheckExcept is implemented in systems that do not 
10 otherwise support exception handling by the use of the setjump and longjump ANSI 

functions. Prior to evaluating the expression, setjump is performed to save the current stack 
frame. If an exception is thrown and it is required to restore the stackframe, longjump is 
performed. 

In addition to the foregoing, the inspection object inherits from idtTest the testrun() method 
15 and other code for running the t_* methods and the code for analyzing the results of the unit 
tests. 

Developing Unit Tests 

The sections that follow provide still further discussion of the operation of the 
inspection class generator 58 and unit test harness 74. Also discussed is designer 
20 modification of the inspection class header and source files 62a, 62b for completing test 
suites for the test harness. 

Although inspection class generator 58 creates most of the unit test code 66 from the 
production class header file 60, the scope of testing may necessitate that the developer 
complete implementation of the test and inspection classes, as well as the test scenarios 

25 themselves. . As noted above, in order to manage the potentially large number of test 
scenarios, the methods are divided into the following logical groups for testing: 
LifeCycle - creation and destruction of the object (tests for memory leaks) 
Set & Query - Accessors and transformers of the object 
Operators - Operator methods 

30 Persist - methods involved in object persistence 
Semantics - methods unique to the class. 
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Each of these groups are implemented in the inspection class as a method 50a - 50e 
whose name is the class prefixed by "tj\ such as t_LifeCycle. In order to preserve the 
isolation of the methods, each test case must be able to be executed on its own, without 
depending on other test cases running before or after it, although test cases may share test 
5 data. 

Testing Object Creation and Deletion — t_LifeCycle 

The purpose of tJLifeCycle is to test the apparent operation of the constructors and 
destructor of the object, including the copy constructor. In addition, because it interacts 
closely with the constructors, the basic assignment operator (=) is tested in t LifeCycle. Th<; 
10 major focus of tJLifeCycle is to catch memory leaks. 

Because memory leaks can not be cleared from a memory manager, it is necessary t< 
create a new manager for each test case. In addition, since the memory manager can only 
check for memory leaks if there are no outstanding blocks of memory allocated, all objects 
constructed using this memory manager must be deleted before the end of the test. A 
15 convenient way to do this is to enclose the test case within a block ( { } ), that way, local 
variables are deleted at the end of the block as they go out of scope. 

Special TLIFE_* macros in idtTest 46 manage the creation of memory managers an 
the block. These macros are: 
TL1FEJNIT- Initialize t_LifeCycle() 
20 TLIFE_START( testname ) - Starts a LifeCycle test case by creating two memory manager?, 
(mm and mm2) and starting a block 

TLIFE END - Ends a LifeCycle test case by closing the block and checking the memory 
managers for leaks (before destroying them). 

Within the scope of the test, two memory managers are available, in the variables m 
25 and mm2. Constructor tests only need one memory manager, but the copy constructor and l 
assignment constructor should be tested with two memory managers to ensure that the data 
completely copied from one object to another. This provides added memory integrity in a 
threaded environment. 

Constructor/Destructor Testing 

30 It is necessary to have at least one test case for each constructor. The strategy for a 

constructor test is as follows: 

1. construct a test object 

2. announce the test object 

3. delete the test object 
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Note that the destructor is tested along with the constructor in these cases. The basic 
test is illustrated in Appendix G. 

Also note the use of the test class, s_erMsg, in this example. The test class should be 
used to represent the production class in all unit test code. 

5 Another consideration in constructor operation is their behavior under error 

conditions. Usually this means testing constructors when there is insufficient memory for the 
new object. 

In one embodiment, out-of-memory exceptions are thrown by the memory manager, 
and caught at the application level, so object constructors are not involved. However, 
10 constructors may require parameter testing. 

Parameter testing should be performed when a parameter's value has some restrictions 
which are enforced by the constructor. In this case, use equivalence partitioning and boundary 
value analysis to determine the necessary test cases. For example, if an object had a member 
which was an unsigned integer, but the only legal values were in the range 1-100. In this 
15 case, test cases need to include calling the constructor with the values 0 (invalid), 1 , 50, 1 00, 
101 (invalid) and 500 (invalid) might be used. 

If the parameters are pointers, test cases should be written to check behavior when the 
parameter is NULL. A test case to check the default constructor needs to be written as well. 

Copy Constructor Testing 

20 Testing the copy constructor follows the form of tests for the regular constructors. 

with slight modifications. In particular, the constructed object should be in a different 

memory area than the copied object to ensure that the copy is completely independent of the 

original. Referring to Appendix H, the scenario is as follows: 

1 . construct an object (obj 1 )with memory manager mm 
25 2. construct the test object, by copying (obj2)with memory manager mm2 

3. check the equality of the objects (if an equality operator exists) (obj 1 =obj2) 

4. delete the original object (obj 1 ) 

5. announce the test object (obj2) 

6. delete the test object (obj2) 

30 Note that deleting the original object catches errors involved with incomplete 

copying. TLIFE_END check both memory managers for leaks. The copy constructor needs to 
have a test case for each constructor. 
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Assignment Operator Testing 

The assignment operator is tested similarly to the copy constructor, although the basii 
scenario is slightly different: 

1 . construct an object (obj 1 ) with memory manager mm 
5 2. construct the test object (obj2) with memory manager mm2 

3. assign the first object to the second object (obj2 = obj 1 ) 

4. check the equality of the objects (if an equality operator exists) (obj 1 =obj2) 

5 . delete the original object (obj 1 ) 

6. announce the test object (obj 2) 
10 7. delete the test object (obj2) 

The assignment operator needs to have a test scenario for each constructor, 
performing the assignment across memory areas. Additionally, the assignment operator need 
two more test scenarios: 

Chains of assignment (obj3 = obj2 ~ obj 1, checking that obj3 = obj 1 ) 

15 Assignment to self: (obj 1 = obj 1 , checking that the obj 1 still contains its value) 

Note that this tests assignment of two like objects; assignment of an object of anothei 
type to a production class object is tested in t_operators. 

Example LifeCycle Test Design 

Consider a class with three constructors: a default constructor, a constructor with 3 
20 dtLong parameters, and a constructor with 3 dtLong and a bcStringi 1 8n parameters, and a 
copy constructor and an assignment operator. It would have twelve test scenarios, as follows 

1 . Default constructor test 

2. Constructor 2 test - values (0, 0, 0) 

3 . Constructor 3 test 1 - values (0, 0, 0, "") 

25 4. Constructor 3 test 2 -values (1,2, 3, "abc") 

5. Copy constructor test 1 - copying object from default constructor 

6. Copy constructor test 2 - copying object from constructor 2 

7. Copy constructor test 3 - copying object from constructor 3 

8. Assignment operator test 1 - assigning object from default constructor 
30 9. Assignment operator test 2 - assigning object from constructor 2 

1 0. Assignment operator test 3 - assigning object from constructor 3 

1 1 . Assignment operator test 4 - chain of assignment 

12. Assignment operator test 5 - assignment to self 
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Testing Set and Query Methods — tJSetQrys 

The purpose of t_SetQrys is to test the operation of the accessors and transformers of 
the class; this includes the Query, Set and Validate methods. 

Query Methods Testing 

5 The query methods should be tested first, because they can then be used to test the Set 

methods. There are two approaches to testing the Query methods. If the method returns an 
unaltered value, the approach is to create an instance of the class with a known value in the 
member(s) being queried, and then check that the query returns these values, as illustrated in 
Appendix I. 

10 Note the use of the TEST() macro; the TEST() macro combines TEST_START(), 

checkExpr() a™* TESTEND macros, allowing a test which consists of a single expression to 
be tested in a single line. Since the example test case consists of the expression, "fdMsgTest3 
= qryMsgID( msgl the test can be implemented as a call to this macro. 

The number of test cases that are needed to validate a query method depends on the 
15 complexity of the query and boundary conditions. In some queries, the member being 
queried may not be present; remember to test both the positive (member present) and the 
negative (member absent) cases, as illustrated in Appendix J. Null and 0 are the most 
common boundary values; always consider whether test cases for these need to be written. 

Another consideration occurs when the value being queried undergoes some 
20 transformation either at creation or during the query. In this case, additional test cases would 
need to check the special cases, assumptions, or boundaries that the calculation imposed on 
the data. For example, a date class which stored its value in terms of month, day, year, but 
included a method qry DayOfYear() which calculates the number of days since the start of the 
year. This method adds to the class of valid test data the conditions of leap and non-leap years 
25 (and skipped leap years at century boundaries), and the special case of the year 1752; test 

cases need include February 29 and December 3 1 , for both a leap and non-leap years, dates in 
the skipped leap years, such as 1900, and dates in 1752 (depending on locale). 

There are no restrictions in setting up test data which satisfies several query unit tests 
at once, as shown in Appendix J. 
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Set Methods 

The approach to testing the set methods is to apply the method and check the results 
with the appropriate query method(s). Test cases need to be written to test all of the boundar; 
conditions in the same manner as for query methods described above. 

5 Testing Operators — ( Operators 

The set of all possible operators is large; all of the operators are considered here, for 
completeness. However it is expected that for any particular class only a few operators will 
be defined. 

The general approach for operator testing is to use equivalence partitioning and 
10 boundary values to establish a list of test inputs and compare the result of the operation with 
constant value. As with query and set methods, the comparison operators should be checked 
first, so that they can be used to test the other operators. 

In the inspection class, the instrumented versions of the operators become procedura 
methods, so they are renamed, for example, "operator*" becomes "oper _plus" 

15 Note that negative testing of operators will likely result in the production code raisin 

exceptions. 

Conversion Operators 

The conversion operators are casts which convert the production class into another 
class. In many cases there is a natural mapping between the class and the target class; even 
20 so, make sure to check the 0/Null boundary. Where a natural mapping does not exist, check 
the code for special cases and equivalence classes. 

Conversion operators are renamed in the inspection class to "opertype", where type 
is the result of the cast. So in our example, the cast to dtLong* is renamed oper_dtLong in t. 
inspection class. The original, in erMsg is: 

25 IllllllllllllllllllltllllllllllllllllUIIIIIIIIII 
II ! METHOD_DECL_S 
// !NAME erMsg_operator_dtULong() 
// ISATISIFIES 

II 1) 
30 // !TEXT 

// erMsg conversion operator. Causes the 
// value of the error message to be returned. 
// Shorthand for qryMsgID(). 
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII 
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operator dtULongO const; 

This is tested in i_erMsg as follows: 

// 

// Test 1 : Cast to dtULong 

5 // 

const dtULong test lvalue = 1 ; 

s_erMsg* msgl = newlnstance( testl value, ERMSGTEST_NAME, ERMSGTEST_5, 
FILE , _LINE_, mm ); 

10 

// Do cast and check the value 
TEST( M Cast to dtULong", testl value = oper_dtULong( msgl ) ): 

deletelnstance( msgl ); 

15 Testing Object Persistence — ( Persist 

The purpose of tJPersist is to test the object persistence for the class: this includes the 
Persist and Fetch methods. 

Testing Unique Methods — t Semantics 

The purpose of t_Semantics is to test those methods unique to the class. 

20 Test Execution Code 

The inspection class generator 58 creates the code which allows the single unit tesi 
harness 74 to run the tests. The harness 74 collects arguments from the user to run the test 
Then, the test harness 74 calls two exported routines: testnameQ and testmainf). to figure out 
what is being tested and to execute the tests. testnameQ returns a dtChar * which names the 

25 inspection class. testmainO serves as the top level of test execution, calling testrun() which, 
in turn, calls inspection class methods which test the production class. In the inspection 
class, two macros are used, TESTRUNdeclare and TESTRUN (supplied in idtTest 46). so that 
testmain is not coded directly. Implementation of these routines is illustrated in Appendix K 
in which the class "erMsgi" refers to the class "i_erMsg. M 

30 Once the inspection class code has been written, it is built into a dynamic link library, 

or "DLL." Each inspection class must have its own DLL, so that the testnameQ and testrunQ 
routines do not clash. 
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Running Unit Tests 

Using the Unit Test Harness 

In a preferred embodiment, when the unit test harness 74 is started up, it brings up th 
window shown in FIGURE 11. The user fills in the first text field with the name of the DLI 
5 built with the inspection class (omitting the .dll extension), and the second text field with the 
name of the file to which report output is to be directed. The user also selects the desired 
verbosity level for each test suite member method and hits the "Run" button. 

The unit test harness 74 then loads the inspection class DLL. and executes the 
testnameQ and testrunQ routines to perform the unit tests. When the tests are complete, the 
10 "Error count" field is filled with the number of errors detected during the run. Pressing the 
View Results buttons will bring up a multi-document notepad with the various output files. 

Output of Unit Tests 

Types of Unit Test Output 

Aside from counting the number of errors detected, the unit test code 74 outputs 
15 messages in three categories: error messages, status messages and debugging information. 
The first class of messages demonstrates whether the production code has correct behavior: 
they are generated by checkExpr(), checkExcept(), checkMemMgr(), TEST(), and 
TLIFE_END macros when an expression fails to evaluate to TRUE or when a memory leak 
is detected. The second type of messages allows the execution of the unit tests to be traced 
20 and they are generated by the TEST_START(), TEST END, TLIFE_START(), TLIFL IN 
macros and by code generated by the inspection class generator. The third class enables 
debugging; these messages are generated by the announceObject and code added by the 
developer. 

A user may need some or all of these messages, depending on their goal in executing 
25 the unit tests. If they only wish to determine if the production code is operational, for 

example, they may just want the error messages. In order to give the user some control over 
the classes of messages they receive, each message has an associated "verbosity level." If th 
current verbosity level is equal to or higher than the level of the message, that message is pi 
into the output stream. This is the effect of the verbosity widget in the unit test harness; by 
30 setting the verbosity higher or lower, the user can control what message they get. The 
verbosity level of the unit test messages are listed below. 
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Verbosity 


Class 


Sample Messages 


SKIP 


Skip particular test 
suite 


SKIPPING: t_LifeCycle, verbosity set to SKIP 


OFF 


None 




LOW 


Error messages 


ERROR: in test FOO, file FILE, line LINE, 
bad expression: EXPR 


MED 


Status messages 


Starting test FOO 
PASS: FOO 


HIGH 


Object dumps, other 
debug messages 


Current value of mDate: FOO 



If the user sets the verbosity level to OFF, the unit tests will not output any messages, 
but if they set the verbosity level to MED, they will get the error and status messages in the 
output log file. Appendices L, M and N depict of test runs at the various verbosity levels. 
SKIP allows execution of a test suite to be skipped, e.g., for purposes of initial test 
5 development and debugging. 

In addition, the inspection class appends a simple analysis of the run at the end of a 
unit test execution. testmain() always returns the number of errors detected, so the test 
harness can display this information even with the verbosity level set to OFF. At LOW and 
MED verbosity levels, the unit test code 74 reports on the number of tests run and the number 
10 of errors found. At HIGH, coverage information is output; this allows the user to determine 
whether all of the production methods were tested. 

Unit Test Output Files 

Output by harness 74 and, particularly, by reporting members 82 is placed into five 

files: 

15 Log file: <file>.out (<file> represents the destination file field in the unit test harness) 
Error file: <file>.err 
Memory Log file: memory.log 
Exception Log file: except.log 
Database Error file: sqlerror.log 

20 The log file is the main file for unit test output. All of the output generated by the unit 

test code is placed into this file, giving the user a place where they can read the messages in 
context. As described above, the contents of the log file is controlled by setting the verbosity 
level. 

The error file separates the error messages from the rest of the output for easier 
25 management. It is not affected by the verbosity level; it always contains all of the error 
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messages generated by the unit test code. The memory log file includes information output I: 
the memory management code, which can be useful in tracking down memory leaks. The 
exception log includes information on the exceptions which were thrown by the unit test 
code. 

5 GENERATION TECHNIQUES 

In an alternative embodiment, as inspection class 34 as described comprises an 
"inspection standard" class and an "inspection custom" class, the latter (i.e., the custom clas 
deriving from the former (i.e., the standard class). The inspection standard class includes al 
of inspection methods 50F (Figure 6), while the inspection custom class includes the test 
10 suites 50A - 50E. Those skilled in the art will appreciate that this facilitates maintenance oi 
the system and, particularly, facilitates regeneration of the inspection standard class as 
necessitated when the API of the production class changes. 

SUMMARY 

Described above are improved methods and apparatus for testing object-oriented 
15 programming constructs. It will be appreciated that the illustrated embodiment is described 
by way of example and that other embodiments incorporating modifications may well fall 
within the scope of the invention. Thus, for example, it will be appreciated that class name: 
function names and variable names may differ from those used herein. In view of the 
foregoing, what we claim is: 
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//^//////////// //////////////////// 
// FILE_^AME: /1jtg)hh 



/////////////// 
// 



///////////////// 



// Copyright 1993 by Marcam Corp., Newton, MA USA 
// 

// This unpublished copyrighted work contains 
// TRADE SECRET information of Marcam Corporation. 
// 

// Use, transfer, disclosure, or copying without 
// its expressed written permission is strictly 
// forbidden. 
// 
// 

/////////////////////////////////////////////////////////////;////////, 




Kifndef utgHHN . 
tdefine utgHH J 

•include •dtcore.hh 



>>4 



// For dtCore 



//////////////////////////////////////////////////////////////////////,/ 
// 1 CLASS_DE£fc s _S r 

// !LIBRA»X^R> 

// !NAME/utgy —7 
// •TEXT^-^ -f 

// Test case for the unit test generator. This class header attempts 
// to test a number of different items that need to be transformed 
y/ when creating the inspection class header. This includes the 
// public and protected member functions, operators, static and nonstatic 
// member functions, and nonclass functions appearing in a header file. 
// Also, various styles of using spaces in a member function delcaration 
// are tested. 
// 

// ! AUTHOR John Dalton (daltonQopl.com) 

// ! REVIEWER <Reviewer's name> <(Reviever*s E-mail address) > 
// !REVIEW_DA7£ <date> 

//////////////////^/////////////////////////////////////z mini /// //// 

class EXPORT (^TT public dtCore 
public:— ^ 

// Public enumeration should not end up in inspection class, 
enum stringSize 

STRINC_SIZE « 10 //O 




////////////////////////////////////////////////, 

// !METHOD_DECL S 

// .'NAME utg def ctor 

// !TEXT 

// The default constructor. Most classes are 
// required to have one. 

///////////////////////////////////////////////// 
utg( dtMemoryMgr* aMemMgr ); 



// !METHOD_DECL_S 
// JNAME utg^ctorl 



APPENDIX A 
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// !TEXT 

// This constructor takes 3 arguments, all of which are required 
///////////////////////////////////////////////// 



utg< dtULong aArgl, 
const dtChar* const aArg2, 
dtMemoryMgr* aMemMgr ); 



///////////////////////////////////////////////// 

// !METHOD_DECL_S 
// J NAME utg_ctor2 
// !TEXT 

// This constructor takes 4 arguments, all are required. 

y//////////////////////////////////////////////// 



utg( dtULong aArgl, 
const dtChar* const aArg2, 
dtlnt aArg3. 
dtMemoryMgr* aMemMgr i j 



/////////y////// //////////// ///////////////////// 

// !METHOD_DECL_S 

// J NAME utg_copy ctor 

y/ !TEXT 

// utg ccpy constructor. 

y//////////////////// //////////////// //////////// 

utg(const utg& aUtg, 

dt Memory Mgr* aMemMgr= (dtMemoryMgr* ) NULL) ; 




/2- 



///////////////////////////////////////////////// 
// l METHOD_DECL_S 
y/ I NAME utg_dtor 
// !T£XT 

y/ utg destructor. Does nothing special. 
///////////////////////////////////////////////// 

-Utg ( ) ; 

///////////////////////////////////////////////// 
// !METKOD_DECL_S 
// JNAME utg_operator= 
// 'TEXT 

// utg assignment operator. 

///////////////////////////////////////////////// 
utg* operators < const utgfc aRhs ) ? 

//y/////////////y////////////////////// ///////// , 

y/ !METHOD_DECL_S 
// iNAME utg_operator_dtULong<) 
it !TEXT 

y/ utg conversion operator. 

Mimujimmumtummmmmmmuu 

operator dtULong () const; 
y//////y//////y//y////////////// ///////////////// ' 

// !METHOD_DECLuS 

// !NAME utg_operator*s(> 

// !TEXT 

// An overloaded Addition Assignment operator 
///////////////// /////////////////////// ///////// 
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/4 



utgfc operator += ( dtlnt aRhs); 

innuinunuuitnniitiniiinnmmmm 

// !M£THOD_DECL_S 
// !NAME utg.openForRead 
// !TEXT 

// Static method generates a utg. 
// Static specifier is dropped on inspection 
// member function. 

Mininnummmmmtjnuumummm 

static erstatus openForRead< utg*4 aUtg. dtMemoryMgr* aKM) ; 

//public ■-Jjrj.t.. Should not appear in generated inspection class^ 
dtChar publicIDstring |STRINC_SIZE) ; 




protected: 



// 2 NAME utg.operatorl ] O 
// ITEXT 

// An overloaded index operator. 
/////////////////////// ////////////////////////// 

dtChar operator (]( dtlnt alndex ) const; 




[UJJJJJ LLLi n u n n n n n n f 1 ^ f f n / n u i / / / t y 



// 
// 
// 



!ME7H0D_DECL_S 
!NAME utg ^«JD 
! TEXT rfN 
// Returns ID. A pure virtual member function. 
// makes this an abstract class. These don't 
// get tested by the unit test, but must be 
/; declared (as private) in the inspection class 
// to satisfy compiler (instantiating an abstra: 
// class). No source is generated for this, it 
// can be declared and implemented. 
//////////////////////////// ///////////////////// 

virtual dtULong rtnlDO const = 0; 



// !NAME utg set ID 
// !TEXT 

J / t w et th ? has an optional parameter. 
// Virtual function declaration is not used 
// on generated inspection member function 

virtual dt Boolean set ID { const dtULong alD, 

const dtChar* const aName « < const dtChar* const) NULL ) 

•ifdef OPLDEBUC 

"/W^'^'r!"""""""""""""''''! 
ft J NAME utg_dump 
// !TEXT 

// This is used by the announceXXX ( ) methods, so 
// there is no need to include this in the 
// generated inspection class. 

///////////////////////// / / ////////////////////// 
dtVoid dumptdtOStreamt aOutStream, dtUInt alndentLevel 

v 8/17/93 7:04PM 
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ieucUf // OPLDEBUC 



// Protected member data. Should not appear in generated inspection class 
dtUInt protectedID; 

dtChar protectedIDstring[STRING_SIZE) ; 



private 




// Of course, nothing private will appear in the inspection class 
dtULong mMsglD; 



///////////////////////////////////////////////// 

// !METHOD_DECL_S 

// !NAME utg_privateMemberFunction 

// 1TEXT 

// Private member functions do noc appear in the 
// generated inspection class. 

y////////////////////// ///////////// ///////////// 

const utg* copy( const utg* const aUtg ) const; 



// Global operator (also a nonclass function) 
utgi operators const utgi ai.hs, const utgi aRhs ) 
•endif // utgHH 



if 



// Honclass function appearing in the header. ^\ 
// These appear in the generated header prepended 
// vitn t-he nair.e of the inspection class. 

ctBoolean export ( const utgi aUtg ) ; 



nde^^p 




2$ 
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////////////////////////////////////////////////////////////////////// 
// ^ \ ^ 



// FILENAME: ^i,utyhh 

// Copyright 1993 by Marcaro Corp., Newton, MA USA 
// 

// This unpublished copyrighted work contains 
// TRADE SECRET information of Marcam Corporation. 
// 

// Use, transfer, disclosure, or copying without 
// its expressed written permission is strictly 
// forbidden. 
// 
// 

////////////////////////////////////////////////////■///// /////////////< 



fifndef i_utgHH 
# define i_utgHH 

•include •idttest.hh- // For idtTest— — A* 

♦include •utg.hh 0 // For utg ^ 



RY I_ER — T ^ X i 



///////////////////////////////////////////////////////////////////////// 

// i CLASS_DECL_S -7 

// i LIBRARY I_ER-^T 

// ! NAME i. 

// !7EXT 

// Generated 7/12/93 by tyutg version 1.0" 
// 

// ! AUTHOR <Author's name> < (Author's E-mail address) > 

// 'REVIEWER <Reviewer*s name> < (Reviewer's E-mail address )> 

// !RZVIEW_DATE <date> 

/////////////////////////////////////// //////////////////////////////'/// 



///;//////////////////////////////////////////// ///////////////////////// 
// Class under test. This class is derived from the production cb}ecc. 
// This provides access to the public and protected member functions 
// of the production class, without modification to the production 
// class. Also, pure virtual functions declared in the production class 
// are provided an implementation here. This allows production abstract 
// base classes to be instantiated and tested. 

//////////////////////////////////////////////////////////// uuminni 

class s_utg : public utg 
1 

public: . I 

friend class i_utg; — ^ I « 

///////////////////////////////////////////////// • 

// Inline constructors, and copy constructor 
// for replicating the production class interface. 

y //////////////////////////////////////////////// 

s_urg( dtMemoryMgr* aMemMgr ) : utg( aMemMgr )() 

s_utg{ dtULong aArgl, 

const dtChar* const aArg2, 

dtMeanoryMgr* aMemMgr ) : utg( aArgl, aArg2, aMemKgr )() 

s_utg< dtULong aArgl, 

const dtChar* const aArg2, 
dtlnt aArg3, 

dtMemoryMgr* aMemMgr ) : utg( aArgl, aArg2, aArg3, aMemMgr )() 
s_utg( const s_utgt aS_utg, 
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dtMemoryMgr* aMemMgr* (dtMerooryMgr*)NULL ) : utg( aS.utg, aMemMgr )(} 



1^ 



immimuummmmmmimimuiiim 

// Provide an implementation for pure virtual 
// functions declared by the production class. 

virtual dtULong rtnlDO const; 

JJiTZX i If this is called you need to add code here ) 




enua FUNCS 

f_nevlnstancel, 
f_newlnstance2. 
f_newlnstanc«3 # 
f_copy!nstance, 
f^deletelnstance, 
f_oper_equal, 
f _oper_dtULong , 
f_oper_plusequal, 
f lope r_ index, 
f_ set ID, 
f_openForRead. 
f _i_utg_export . 
f _ i_u t g_ope r_p 1 u s 
T0TA1<_FUNCS 

}; 



dtlr.t coverage 1 T07AL.FUNCS ) ; 




14 



class EXPORT i_utg : public idtTest 
< 



public: 



/ ///////////// ////////// v/y /////////// /////// //// 
// Inspection class member functions: 

juujiijmunuimtiimunitmiummtn 

i_utg< dtStreamExecutive* aStreamExec, 
" dt Memory Executives aMemExec, 
idtTestArgs4 aTestArgs. 
dtMemoryMor* aTestMM ); 



-i_utgO; 



///////////////////////////////////////////////// 
J I Inspection test suite. 

///////////////////////////////////////////////// 

virtual dtVoid t.LifeCycle() ; 
virtual dtVoid t.Operators O ; 
virtual dtVoid t_SemanticsO ; 
virtual dtVoid t_S«tQrys()j 
virtual dtVoid t_Persist(); 

virtual dtVoid qrycoveraget dtlnt*t aCovAry, dtlntt aNumFuncs ) const; 

/////////////////////////////////////////////////"I 
// Constructors for class under inspection 0 
///////////////////////////////////////////////// 
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s_utg* nevlnstancet dtMemoryMgr* aMemMgr ); 

fi.urg* newlnstancei dtULong aArgl, 
~ const dtChar* const aArg2, 

dtMeaoryMgr* aMemMgr ) ; 

s_utg* nevlnstanceC dtULong aArgl, 
const dtChar* const aArg2, 
dtlnt aArg3, 
dtMemoryMgr* aMemMgr ) ; _ 

///////////////////////////////////////////////// 
// Cop/ constructor for class under inspection. 
///////////////////////////////////////////////// 

s_utg* copy Instance ( s.utg* a Instance, 

dtMemoryMgr* aMemHgr= (dtMemoryMgr*) NULL) ; 



///////////////////////////////////////////////// 

// Destructor for class under inspection. 

///////////////////////////////////////////////// 

dtVoid deletelnstance ( s_utg* alnstance }; 

///////////////////////////////////////////////// 
// Other member functions. 

//////////////✓/////////////////// /////////////// 



10 




22- 



> ^ 

erStatus openForReadt s_utg # & aUtg. dtMemoryMgr* al-lxT^^^* 

7> 



•s.utgt oper_equal< s_utg* alnstance, 
const s.utgt aRhs ) ; 

•atULong oper_dtULong ( s_utg* alnstance ); 

0?»_s_utgii oper_plusequal < s_utg* alnstance, 
^ dtlnt aRhs > ; 



dtChar oper_index< s_utg* alnstance, 
dtlnt a Index ) ; 



dtBoolean setlDt s.utg* alnstance, 
const dtULong aID,» 

const dtChar* const aName * (const dtChar* const) NULL ) 



private: 



//////////////////////////////////////// 
// Inspection class member functions, unimpl 
// copy constructor and assignment operator 
///////////////////////////////////////////////// 



i_utg< const i_utgt al_utg ); 

i_utgi operators ( const i_utgi al_utg )t 



/////////V 

implemented X 

' \3t 



///////////////////////////////////////////////// 
// None lass functions to be tested. 
///////////////////////////////////////////////// 

dtBoolean i^utg.export ( idtTest* aTestObJ, const s_utg4 aUtg 

s_utgfc i_utg_oper_plus < idtTest* aTestObj, const s_utgfc aLhs, const s.utgt aRhs ,;>33 



•endif // i_utgHH 
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s_utg* copy Instance { s_utg* ci fiance, 

dtMemoryMgr* aMemMgr= (dtKemoryMgr*)NULL) ; 



///////////////////////////////////////////////// 
// Destructor for class under inspection. 

/////////////////////J//////// //////////// /////// 

dtVoid deletelnstance [ s_utg* alnstance ); 

///////////////////////////////////////////////// 
// Other member functions. 

////S///////////J//////// ///////////////// //////' 



A 



f •oper_egual* tests *operator= 
r s__ utgi oper_egual< s_utg* alnstance, 



J? *oper_dtULong* tests 'operator dtULongt)' BfiiwirC' ">^^o 

^/cJtULong oper_dtULong ( s_utg« alnstance ); ^ OpEj^^/rS 

S.'/ -oper_plusequal* tests • operator* = • , ^ QD O^A<rbJZ+ 5> DDtTP d^i 

s_utgi oper_plusequal < s_utg- alnstance, ^ r ^evv. - AJ^^- 
dtlnt aRhs ) ; 

erStatus openForRead( s_utg # fc aUtg; dtMemoryMgr* aKM) ; 

oper_ind€x- tests 'operator! ] • ^ 006)^X2) >^E 1 (PPO^-V(Z 

ar oner index ( s uta* alnstance. I 



dtChar oper_.index( s_utg* alnstance 
dtlnt alnd^x ); 

dtBoolean setID( s_utg* alnstance, 
const dcULong alD, 

const dtChar* const aName = (const dtChar* const) NULL ); 



>rivate: 



///////////////////////////////////////////////// 

// Inspection class member functions, unir.pieroented 
// copy constructor and assignment operator. 
///////////////////////////////////////////////// 

i_utg( const i_utgt al_utg ); 

i_utgi operator^ { const i_utc& al_utg ); 



//////////////////////////////////////// //////// 
I Nonclass functions to be tested. 
//////////////////////////////////////////////// 

tBoolean i_utg_export ( idtTest* aTestObj, const s_utg& aUtg ); 

_utgi i_utg_oper_plus( idtTest* aTestObj, const s_utg& aLhs, const s_utg& aRhs )j 



endil J! J_utgHH 
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Test Code 
(procedural) 



Production Code 
(procedural) *' 



testfunc( ... ) 
{ 

environment init. 
memory allocation 
test initialization 
test code 
print results 
test cleanup 
test initialization 
test code 
print results 
test cleanup 
} 



Figure 1 

(prior art) 
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said inspection object execution means includes means for executing a method 
member of said inspection object for invoking one or more test suite members. 

80. An apparatus according to claim 69, wherein 

said inspection object execution means includes means for placing said digital data 
processor in a desired runtime environment. 
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results of such invocation, and for generating said report signal to be indicative of such 
comparison. 

74. An apparatus according to any of claims 69 and 73, wherein 

said inspection object execution means includes means for executing one or more 
5 member methods of said inspection object to generate said report signal. 

75. An apparatus according to any of claims 69, wherein: 

said inspection object execution means includes means responding to a verbosity 
control signal to generate said report signals with corresponding verbosity. 

76. An apparatus according to claim 69. wherein 

10 said inspection object execution means includes means for executing one or more 

method members of said inspection object, referred to hereinafter as inspection members, k 
testing corresponding method members of said test object. 

77. An apparatus according to claim 76. wherein 

said inspection object execution means includes means for executing one or more 
15 members of said inspection object, referred to hereinafter as test suite members, for 
exercising one or more of said inspection members. 

78. An apparatus according to claim 77, wherein 

said inspection object execution means includes means for executing said test suite 
members for at least one of 

20 (i) testing for memory leaks in connection with at least one of creation and destruction 



said test object. 


(ii) 


testing accessor and transformer members of said test object. 


(iii) 


testing operator member methods of said test object. 


(iv) 


testing members involved in persistence of said test object, and 


(v) 


testing method members semantically unique to said test object. 


79. 


An apparatus according to claim 77 ? wherein 



WO 96/12224 



PCT/US95/06059 



79 



for creating an inspection object instantiating an inspection class, and for generating 
an inspection object invocation signal for invoking one or members thereof, 

(B) inspection object execution means, coupled to said test harness means, for responding 
to said inspection object invocation signal for 

5 (i) creating said test object, 

(ii) generating a test object invocation signal to invoke one or more selected method 
members of said test object, 

(Hi) generate a signal, hereinafter referred to as a report signal, reporting an effect of such 
invocation, 

10 (C) test object execution means, coupled to said inspection object execution means, for 
responding to said test object invocation signal to execute one or more selected method 
members thereof. 

70. An apparatus according to claim 69. wherein 

said inspection object execution means includes means for creating said test object as 
15 an instantiation of a test class that comprises any of 

(a) said subject class, and 

(b) an instantiate class derived from said subject class. 

71. An apparatus according to claim 69, wherein 

said inspection object execution means includes means for applying at least one 
20 argument to one or more of said selected method members of said test object in connection 
with invocation thereof. 

72. An apparatus according to claim 69. wherein 

said inspection object execution means includes exception service means preventing 
exceptions that occur during invocation of said one or more selected method members from 
25 discontinuing at least reporting on effects of invocation of said test object. 

73. An apparatus according to claim 69, wherein 

said inspection object execution means includes means for comparing a result of 
invocation of said one or more selected method members of said test object with expected 
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said inspection object execution means includes means for executing one or more 
members of said inspection object, referred to hereinafter as test suite members, for 
exercising one or more of said inspection members. 

66. An apparatus according to claim 65, wherein 

5 said inspection object execution means includes means for executing said test suite 

members for at least one of 

(i) testing for memory leaks in connection with at least one of creation and destruction < 
said test object. 

(ii) testing accessor and transformer members of said test object. 
10 (iii) testing operator member methods of said test object. 

(iv) testing members involved in persistence of said test object, and 

(v) testing method members semantically unique to said test object. 

67. An apparatus according to claim 65. wherein 

said inspection object execution means includes means for executing a method 
15 member of said inspection object for invoking one or more test suite members. 

68. An apparatus according to claim 57, wherein 

said inspection object execution means includes means for placing said digital data 
processor in a desired runtime environment. 

69. Apparatus for testing a subject class in an object-oriented digital data processing 
20 system, said apparatus comprising: 

(A) test harness means for responding to an inspection signal defining an inspection cla; 
having one or more members for 

(i) creating a test object as an instantiation of any of said subject class and a class denv 
therefrom. 

25 (ii) invoking one or more selected method members of said test object, 

(iii) generating a signal, hereinafter referred to as a report signal, reporting an effect of 
such invocation 
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(a) said subject class, and 

(b) an instantiate class derived from said subject class. 

59. An apparatus according to claim 57, wherein 

said inspection object execution means includes means for applying at least one 
argument to one or more of said selected method members of said test object in connection 
with invocation thereof. 

60. An apparatus according to claim 57. wherein 

said inspection object execution means includes exception service means preventing 
exceptions that occur during invocation of said one or more selected method members from 
discontinuing at least reporting on effects of invocation of said test object. 

61 . An apparatus according to claim 57. wherein 

said inspection object execution means includes means for comparing a result of 
invocation of said one or more selected method members of said lest object with expected 
results of such invocation, and for generating said report signal to be indicative of such 
comparison. 

62. An apparatus according to any of claims 57 and 59. wherein 

said inspection object execution means includes means for executing one or more 
member methods of said inspection object to generate said report signal. 

63. An apparatus according to any of claims 61 . wherein: 

said inspection object execution means includes means responding to a verbosity 
control signal to generate said report signals with a selected level of verbosity. 

64. An apparatus according to claim 57. wherein 

said inspection object execution means includes means for executing one or more 
method members of said inspection object, referred to hereinafter as inspection members, for 
testing corresponding method members of said test object. 

65. An apparatus according to claim 64, wherein 
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said code generator means includes means for generating said inspection signal to 
define said inspection class to include one or more method members, referred to hereinafter 
as test suite members, for exercising one or more of said inspection members. 

54. An apparatus according to claim 53, wherein 

5 said code generator means includes means for generating said inspection signal to 

define said inspection class to include one or more method members, hereinafter referred to 
as run members, for invoking said one or more test suite members. 

55. ' An apparatus according to claim 53. wherein 

said code generator means includes means for generating said inspection signal to 
10 define said inspection class to include one or more method members providing common 
services for invocation by said test suite members. 

56. An apparatus according to claim 53, wherein 

said code generator means includes means for generating said inspection signal to 
define said inspection class to include one or more method members providing common 
15 reporting services for invocation by said test suite members. 

57. An apparatus according to claim 50, comprising: 

(A) inspection object execution means, coupled to said test harness means, for respondir 
to said inspection object invocation signal for 

(i) creating said test object. 

20 (ii) generating a test object invocation signal to invoke one or more selected method 
members of said test object, 

(iii) generate a signal, hereinafter referred to as a report signal, reporting an effect of sue 
invocation, 

(B) test object execution means, coupled to said inspection object execution means, for 
25 responding to said test object invocation signal to execute one or more selected method 

members thereof. 

58. An apparatus according to claim 57. wherein 

said inspection object execution means includes means for creating said test object 
an instantiation of a test class that comprises any of 
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responding to a verbosity control signal to generate said report signal with a selected 
level of verbosity. 

50. Apparatus for testing a subject class in an object-oriented digital data processing 
system, said apparatus comprising: 

5 (A) code generator means for responding to a source signal defining said subject class to 
generate an inspection signal defining an inspection class having one or more members for 

(i) creating a test object as an instantiation of any of said subject class and a class derived 
therefrom, 

(ii) invoking one or more selected method members of said test object, 

10 (iii) generate a signal, hereinafter referred to as a report signal, reporting an effect of such 
invocation, and 

(B) test harness means, coupled to said code generator means, for responding to said 
inspection signal for creating an inspection object instantiating said inspection class, and for 
generating an inspection object invocation signal for invoking one or more members thereof. 

15 51. An apparatus according to claim 50, wherein 

said code generator means includes test class generating means for responding to said 
source signal to generate a test signal defining a test class that comprises any of 

(i) said subject class, and 

(ii) an instantiate class derived from said subject class, and wherein 

20 said code generator further includes means for generating said inspection signal to define said 
inspection class to include one or more members for creating said test object as an 
instantiation of said test class. 

52. An apparatus according to claim 50, wherein 

said code generator means includes means for generating said inspection signal to 
25 define said inspection class to include one or more method members, referred to hereinafter 
as inspection members, for testing corresponding method members of said test object. 



53. 



An apparatus according to claim 52. wherein 
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step (B)(ii) includes the step of invoking one or more method members of said 
inspection object, referred to hereinafter as inspection members, for testing corresponding 
method members of said test object. 

44. A method according to claim 43. wherein 

5 step (B)(ii) includes the step of invoking one or more method members of said 

inspection object, referred to hereinafter as test suite members, for exercising one or more ol 
said inspection members. 

45. A method according to claim 44, wherein 

step (B)(ii) includes the step of invoking one or more test suite members to at least 

10 one of 

(i) test for memory leaks in connection with at least one of creation and destruction of 
said test object. 

(ii) test accessor and transformer members of said test object. 

(iii) test operator member methods of said test object. 

15 (iv) test members involved in persistence of said test object, and 
(v) test method members semantically unique to said test object. 

46. A method according to claim 44, wherein 

step (B)(ii) includes the step invoking one or more method members of said 
inspection object for invoking one or more test suite members. 

20 47. A method according to claim 34, wherein 

step (B)(i) includes the step of placing said digital data processor in a desired runtin: 
environment. 

48. A method according to any of claims 38 -42, comprising: 

invoking one or more method members of said inspection object to generate said 
25 report signal. 

49. A method according to any of claims 48, comprising; 
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36. A method according to claim 34, wherein 

step (B)(ii) includes applying at least one argument to one or more of said selected 
method members of said test object in connection with invocation thereof. 

37. A method according to claim 36, wherein 

5 step (B)(ii) includes applying at least one argument to a constructor member of said 

test object in connection with creation of said test object. 

38. A method according to claim 34. wherein 

step (B)(ii) includes the step of preventing exceptions that occur during invocation of 
said one or more selected method members from discontinuing execution of steps (B)(ii) and 
10 (B)(iii). 

39. A method according to claim 34. wherein 

step (B)(iii) includes comparing said result of such invocation with one or more 
expected values thereof, and generating said report signal to be indicative of such 
comparison. 

15 40. A method according to claim 39. wherein 

step (B)(iii) includes the step of storing a signal indicative of said effects in a dau 
member of said inspection object. 

41. A method according to claim 34, wherein 

said method includes the step of executing step (B) a plurality of times, each lor 
20 invoking a different group of one or more selected method members of said test object. 

42. A method according to claim 41 , wherein 

step (B)(iii) includes the step of generating said report signal to be indicative ot at 
least one of 

(i) comparison of results of invocation of one or more method members of said test 
25 object with one or more expected values thereof, and 

(ii) detection of a memory leak. 

43. A method according to claim 34. wherein 
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step (B)(i) includes the step of placing said digital data processor in a mode of a 
desired runtime environment. 

32. A method according to any of claims 20 - 25, comprising: 

invoking one or more method members of said inspection object to generate said 
5 report signal. 

33. A method according to any of claims 32, comprising: 

responding to a verbosity control signal to generate report signals with a selected lev 
of verbosity. 

34. A method for testing a subject class in an object-oriented digital data processing 
10 system, said method comprising: 

(A) creating an inspection object as an instantiation of an inspection class having one or 
more members for 

(i) creating a test object as an instantiation of any of said subject class and a class derivt 
therefrom, 

15 (ii) invoking one or more selected method members of said test object, 

(iii) generating a signal, hereinafter referred to as a report signal, reporting an effect of 
such invocation 

(B) invoking one or more members of said inspection object to 
(i) create said test object, 

20 (ii) invoke one or more selected method members of said test object, 

(iii) generate a signal, hereinafter referred to as a report signal, reporting an effect of sue: 
invocation. 

35. A method according to claim 34, wherein 

step (B)(i) includes the step of creating said test object as an instantiation of a test 
25 class that comprises any of 

(a) said subject class, and 

(b) an instantiate class derived from said subject class. 
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(i) a comparison of results of invocation of one or more method members of said test 
object with one or more expected values thereof, and 

(ii) detection of a memory leak. 

26. A method according to claim 1 7, wherein 

said method includes the step of executing step (B) a plurality of times, each for 
invoking a different group of one or more selected method members of said test object. 

27. A method according to claim 1 7, wherein 

step (C)(ii) includes the step of invoking one or more method members of said 
inspection object, referred to hereinafter as inspection members, for testing corresponding 
method members of said test object. 

28. A method according to claim 27, wherein 

step (C)(ii) includes the step of invoking one or more method members one or more 
members of said inspection object, referred to hereinafter as test suite members, for 
exercising one or more of said inspection members. 

29. A method according to claim 28, wherein 

step (C)(ii) includes the step of invoking one or more test suite members to at leasi 

one of 

(i) test for memory leaks in connection with at least one of creation and destruction of 
said test object, 

(ii) test accessor and transformer members of said test object, 

(iii) test operator member methods of said test object, 

(iv) test members involved in persistence of said test object, and 

(v) test method members semantically unique to said test object. 

30. A method according to claim 28, wherein 

step (C)(ii) includes the step invoking one or more method members of said 
inspection object for invoking one or more test suite members. 



31. A method according to claim 1 7, wherein 
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1 8. A method according to claim 1 7, wherein 

step (C)(ii) includes applying at least one argument to one or more of said selected 
method members of said test object in connection with invocation thereof. . 

1 9. A method according to claim 1 8, wherein 

5 step (C)(i) includes applying at least one argument to a constructor member of said 

test object in connection with creation thereof. 

20. A method according to claim 1 7. wherein 

step (C)(ii) includes the step of preventing exceptions that occur during invocation oi 
said one or more selected method members from discontinuing execution of steps (C)(ii) anc 
10 C(iii). 

21. A method according to claim 1 7. wherein 

step (C)(iii) includes comparing said result of such invocation with one or more 
expected values thereof, and generating said report signal to be indicative of such 
comparison. 

15 22. A method according to claim 1 7. wherein 

step (C)(iii) includes the step of storing said report signal in a data member of said 
inspection object. 

23. A method according to claim 22, wherein 

step (C)(iii) includes the step of storing in said data member of said inspection objec 
20 a signal indicative of a number of errors incurred in connection with invocation of said one < 
more selected method members of said test object. 

24. A method according to claim 23. wherein 

step (C)(iii) includes the step of storing in said data member of said inspection objec 
a signal indicating coverage of testing associated with invocation of said one or more methc 
25 members of said test object. 

25. A method according to claim 22. wherein 

step (C)(iii) includes the step of generating said report signal to be indicative of at 
least one of 
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step (A) includes the step of generating said inspection signal to define said inspection 
class to comprise one or more method members providing common reporting services for 
invocation by said test suite members. 

13. A method according to claim 7, wherein 

5 step (A) includes the step of generating said inspection signal to define said inspection 

members to include method member functions corresponding to at least one constructor in 
said test object, wherein each of those method member functions take substantially the same 
arguments as the corresponding constructor in said test object. 

1 4. A method according to claim 7, wherein 

10 step (A) includes the step of generating said inspection signal to define said inspection 

members to include method member functions corresponding to a destructor in said test 
object. 

15. A method according to claim 7, wherein 

step (A) includes the step of generating said inspection signal to define said inspection 
15 members to include method member functions corresponding to at least one operator function 
in said test object, 

16. A method according to claim 7. wherein 

step (A) includes the step of generating said inspection signal to define said inspection 
members to have function names similar to those of the corresponding method members of 
20 the test object that they test. 

1 7. A method according to claim K comprising the step of 

(B) responding to said inspection signal to create an inspection object as an instantiation 
of said inspection class, and 

(C) invoking one or more members of said inspection object to 
25 (i) create said test object, 

(ii) invoke one or more selected method members of said test object. 



(iii) generate a signal, hereinafter referred to as a report signal, reporting an effect of such 
invocation. 
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step (B) includes the step of generating said test signal to define said test class to giv- 
instantiations of said inspection class access to members of said subject class. 

7. A method according to claim 1 , wherein 

step (A) includes the step of generating said inspection signal to define said inspectk 
5 class to include one or more method members, referred to hereinafter as inspection memben 
for testing corresponding method members of said test object. 

8. A method according to claim 7. wherein 

step (A) includes the step of generating said inspection signal lo define said inspects 
class to include one or more method members, referred to hereinafter as test suite members. 
10 for exercising one or more of said inspection members. 

9. A method according to claim 8. wherein 

step (A) includes the step of generating said inspection signal to define said test suit* 
members to include one or more members for at least one of 

(i) testing for memory leaks in connection with at least one of creation and destruction - 
15 said test object, 

(ii) testing accessor and transformer members of said test object, 

(iii) testing operator member methods of said test object, 

(iv) testing members involved in persistence of said test object, and 

(v) testing method members semantically unique to said test object. 
20 10. A method according to claim 8, wherein 

step (A) includes the step of generating said inspection signal to define said inspecti 
class to include one or more method members, hereinafter referred to as test run members. : 
invoking said one or more test suite members. 

11. A method according to claim 8. wherein 

25 step (A) includes the step of generating said inspection signal to define said inspect 

class to comprise one or more method members providing common services for invocatioi 
by said test suite members. 

12. A method according to claim 8. wherein 
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CLAIMS : 

1 . A method for testing a subject class in an object-oriented digital data processing 
system, said method comprising the step of: 

(A) responding to a source signal defining said subject class to generate an inspection 
signal defining an inspection class having one or more members for 

(i) creating a test object as an instantiation of any of said subject class and a class derived 
therefrom, 

(ii) invoking one or more selected method members of said test object. 

(iii) generating a signal, hereinafter referred to as a report signal, reporting an effect of 
such invocation. 

2. A method according to claim 1. comprising 

(B) responding to said source signal to generate a test signal defining a test class that 
comprises any of 

(i) said subject class, and 

(ii) an instantiable class derived from said subject class, and 

step (A)(i) includes the step of generating said inspection signal to define said inspection 
class to include one or more members for creating said test object as an instantiation ol said 
test class. 

3. A method according to claim 2. wherein 

step (B) includes the step of generating said test signai to define an instantiable test 
class that inherits one or more members of said subject class. 

4. A method according to claim 3, wherein 

step (B) includes the step of generating said test signal to define said test class to 
substantially duplicate pure virtual functions of said subject class, absent constructs that 
denote those functions as having both pure and virtual attributes. 

5. A method according to claim 3, wherein 

step (B) includes the step of generating said test signal to define said test class to 
substantially duplicate at least one constructor and a destructor of said subject class. 



6. 



A method according to claim 3. wherein 
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METHOD STAXTi t_Llt*Cycl« 

Starting i«iCi Ctorl and Dtor. at lin«> 56. FU«: c : \vi#w\prodn\ f d\arrcr«\ut\imp\«rH»gi .cpp 
METHOD STAXTi Mwln«tanc« 
KSTHOO ENDi nawlnstanea 

OBJECT: 

* *rMSO, • 

• bcStrlngllto ♦ 

* csm_ch*raxt«r » 

V«lu«i crKsgl t_Llf*Cyelc«i\vi«w\prodn\fd\*rrorB\ut\ir.sp\«rKsgi .cpp 
Number of Charat 6S 
- csnv_ch*ractar - 
Advanced! 0 

- bcstringilio - 
t Falst 

« be St ring ilia * 
valu«: NULL 
Advanced i 0 

- bcStringlUn - 
- «r*«g - 

KETHOO STAJtTi dalatal natance 
KTTVOD END: dalatalnatanca 

EMOR: MEMORY LEAK DETECTED IN MEMORY MANAGER, in t«t: Ctorl and Dtor, ac L;nc: 66, FtU: c : w;«*\pro£.v 

FAILED cut: Ctorl and Dtor. at line: 66. Fil«. c:\vjev\prodn\fd\errora\ucwnsp\arKsgi.cpp 
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Starting t*$ti Copy Ctor • Copying Ctorl across Hmry Hgrs. at Una: 133. FUti c i \viaw\prodn\Cd\. . . 
EfWOHi KDORY LEAK DtTECTED IN KEM3RY MANAGER, tn tast t Copy Ctor - Copying Ctorl across Hamcry Kgrs. at Line: U6 
EMORi KEXORY LEAK UtTU- ' lUJ IN KEKDRY MANAGER. In tast: Copy Ctor - Copying Ctorl across Namsry hgrs. at Line: 146 

FXILEI> test: Copy Ctor - Copying Ctorl across Hamory Hgrs, at Una: 116. Fll«; ci \visw\prodn\td\ . . . 

StarUng"c«tVqry!tigID, at Una; 261. Fi c :Wlsw\probn\t<J\arrors\ut\lnsp\«rHsgi .cop 
CHECKS): Expression: qryHsglDt »sg* ) — <2. m tast : qryHsglD. at Una: 248. File: c:\viaw\prodn\fc\... 
PASS tast: qryHsglD. at Una-. 26*. FiU: ct Wisv\prodn\fd\«rrors\ut\insp\erKsgi .cpp 
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DtRCF. : KDCRY L£AK DETECTED IN HDfDRY MANAGER, in tCSC : Ctorl and Dtor. «t LLn* : 66, Til*: C:\vi«w\... 
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TZSTRUNdeclare 1 erMsgi ) 

extern *C* ( 

dtChar • FAR PASCAL EXPORT testnameM 

( 

return ( 'erKsgi" ); 

) 

dtlnt FAR PASCAL EXPORT testmain( idtTestArgs* aTestArgs ) 

return! TESTRUN ( e rMsgl ) ( aTestArgs ) ); 
) 

> // end extern C 
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I_UTC.CPP 



fff/jMi/f// 



n n n in n mi i in n/i i inn n i n 1 1 h in i in i / f 



/!//////////// 

// FILENAME: M.UtcJ.cpp 

// V * 

// Copyright 1993 by Ma ream Corp., Newton, MA USA 
// 

// This unpublished copyrighted work contains 

// TRADE SECRET information of Ma ream Corporation. 

// 

// Use, transfer, disclosure, or copying without 

// Its expressed written permission is strictly 

// forbidden. 

// 

// 



//////y///////////////////////////////////////////////////// ////////// 



•include •i_utg.hh # 



// For i_utg 



- J 

lass ^ 




// Establish an instance of TEST RUN for this c 
TESTRUNdeclare ( i_utg ) 

// 

// TESTRUNM and testname ( ) are used by the unit test harness 
// to run the tests and display the name of the unit test. 
// 

extern - C* dtlnt FAR PASCAL EXPORT testmam( idtTestArgsi aTestArgs ) 
i 

return { TESTR'JN ( i_utg ) < aTestArgs > ); 

) 

extern *C* dtChar * FAR PASCAL EXPORT testname* ) 
I 

return ( •i_utg - ); 

) 




///////////////////////////////////////////////////////////////////////// 
// iCLASS.DES^. 
// JLIBPA?tr^CER 
// !;:AMt(^i_uta 
// ! TEXT 

// Generated 7/12/93 by utg version 1.0 
// 

// « AUTHOR <Author's name> < (Author's E-mail address t> 

// ! REVIEWER < Re viewer's name> < (Reviewer's E-mail address) > 
// ! REV I EW_DATE <date> 

///////////////////////////////////////////////////////////;//////////// 



1 




///////////////////////////////////////////////// 

// Inspection class constructor. 
///////////////////////////////////////////////// 

i_utg: :i_utg< 

dt St ream Executive - aStreamExec, 
dt Memory Executive* aMemExec, 
idtTestArgsL aTestArgs, 
dtMemoryMgr* 

): idtTestf aStreanExec, aMemExec, aTestArgs ) 



{ 



for ( int 1 = 0 ; i < TOTAL. FUNCS ; i** > 
coverage! i J s 0; 



///////////////////////////////////////////////// 
// Inspection class destructor. 
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uuummmmmmminmiitmiimini! 

i_utg: :-i_utg O 
{ 
) 
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///////////////////////////////////////////////// 
// Lifecycle testing. 

// The TLIFE.START and TLIFE_END macros are placed 
// around each lifecycle test. These provide the 
// announcement of each test and whether it has 
// passed or failed. They also provide clean 
// memory mamangers for each test. Throughout 
// the lifecycle test (between the TLIFE.INIT and 
// TLIFE.CLEANUP macros) two memory managers are 
// available: mm and mm2. 

////////////y//////////////////// ////////// ////// 



otVoid 

i_utg: stjLif eCyclet ) 
i 

TLIFE-INIT 

// CONSTRUCTOR/DESTRUCTOR TESTING 
// 
// 
// 

// is construct the 
// 

TLIFE_START( *ctorl and dtor' ) 

s_utg* testobjX = newlnstance( 
^^■"^nnounceObject ( 
deletelnstance ( 
7LIFE_END 





It 



Constructor and destructor testing, 
be performed for each constructor. : 
object, announce it, 



One test must 
"he basic format 
then delete it. 



/•PARAMETERS, V mm )j 



♦testobjX ) ; 
testobjX ) ; 



// COPY CONSTRUCTOR TESTING 
// 

// Copy constructor tests. One test must be performed 
// for each copy constructor/constructor combination. 
// The format for each test is: construct an object 
// using mm, then invoked the copy constructor using 
// t„t.2, delete the original, announce the copy, then 
// delete the copy. This test copying across memory 
// spaces, as well as. incomplete copies and use of 
// aliases (shared pointers with no reference counting) 
// 

TL I FE_ START ( 'Copy ctor and ctorl* ) 

s_utg* testobjX = newinstance( /* PARAMETERS, * / mm >, 
s_utg* testobjY = copylnstance ( testobjX, mm2 ); 

etelnstance( testobjX I; 
announceObject ( 'testobjY ); 
deletelnstance( testobjY ); 
TL1TEJEND 



1- 



// ASSIGNMENT OPERATOR TESTING 
// 

// Similar in nature to the copy constructor testing, 

// one test must be performed for each constructor/ 

// assignment operator combination. The format is: 

// construct objectX using mm, construct objectY 

// using mm2, assign objectX to objectY, check for 

// equality if that operator is defined, delete 

// objectX, announce objectY, delete objectY. 

// Additionally, chained assignment (objZ«objYsobjX, 

// where after the operation objZ == objX) and 

// assignment to self (objX«objX, where objX still 
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;.cpp 



/•PARAMETERS, •/ 
/•PARAMETERS, */ 



// has a value after assignment) must be tested. 
// 

TLIFE_START( •ctorl and operators' ) 
s_utg* testobjX s newlnstancet 
s^utg* testobjY s newlnstancet 
testobjY s *testobjX; 
f//iFIX checkExprt *testobjX «= *testobjY, currTest >; 

deletelnstancet testobjX )i 
announceObject ( • testobjY ); 
deletelnstancet testobjY ); 
TL1TZJEND 

TLIFE_ STAR T ( 'Chained assignment - ) 

1 ' s_utg* testobjX * newlnstancet /* PARAMETERS, */ mm ) 

s_utg* testobjY = newlnstancet /•PARAMETERS. • / mm2 
S-Utg * testobjZ = newlnstancet /* PARAMETERS, •/ mm ) 
-^testobjZ s *testobjY = # testobjX; 
'.'FIX checkExprt •testobjZ s= *testobjY. currTest ); 

deletelnstancet testobjX ); 
deletelnstancet testobjY ); 
announceObject t *testobj2 ); 
deletelnstancet testobjZ ); 
TLIFE.END 




2 2- 



2<i 



TIIFE START ( 'Assignment to self ) 

s.u tg* testobjX = newlnstancet /'PARAMETERS.' 
-estobjX = *testobjX; 

announceObject ( 'testobjX ); 

deletelnstancet testobjX ); 
7LIFE_END 



7LIFE.CLEANUP; 



/ mra ) ; 



///•////////////////////////////////////////////// 
// Operators testing. 
// 

// All operators are tested here. The entire 
// set of operators has been broken into like 
// categories for ease of testing. Between the 
/ / 7_1N'ZT and T_CLEANUP macros the memory manager 
// variable mm is available for constructing 
// test objects. Each individual test must be 
// surrounded by the T_START and T.END macros, 
// or alternately, the test itself can be performed 
// virhin a TEST macro. 

///////////////////////////////////////////////// 
dtvoid 

i_utg : : t_Operators ( ) 
i 

T_INIT( *t_Op*ra tors' ) 

// COMPARISON OPERATORS: <><=>. n= * a 
// ARITHMETIC OPERATORS: ♦ -*/%♦♦-- 
// LOGICAL OPERATORS t I I fcl ! 
// BITWISE OPERATORS: * I & • « » 
// EXTENDED ASSIGNMENT OPERATORS: ♦« -a ♦« /= % s 
// CONVERSION OPERATORS: type ( ) 
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// MISCELLANEOUS AND GLOBAL OPERATORS 



1 



T_CLEANUP 



nmmmmmmimmmmmmmmmh 

// set and Query testing. 

// 7he set and query member functions are tested 
// here. If your class under test contains 
// values that do not require being set first, 
// then test the query methods for those values 
// before testing the corresponding set methods. 
// Between the T.INIT and T.CLEANUP macros the 
// memory manager variable nun is available for 
// constructing test objects. Each individual 
// test must be surrounded by the 7_S7ART and T_END 
// macros, or alternately, the test itself can be 
// performed within a 7ES7 macro. 

uuinjujunnntnuntnunnitmiimiin 

dtvoid 

i.utg: : t_SetQrys < ) 
i 

T_INIT( •t_SatQrys* ) 
// QUERY TESTS 



) 



// SET TESTS 
T_CLEANUP 



///////////// ! 1 1 i I III 1 1 1 ! I! I U 1 II ! i 1 1 ! 1 1 1 ! ! I U I U 
// Semantics testing. 
// 

// These tests are for those member functions 
// unique to the production class. 
// Between the T.INIT and ".CLEANUP macros the 
// n.er.ory manager variable mm is available for 
// constructing test objects. Each individual 
// test rust be surrounded by the 7_ START and T_END 
// macros, or alternately, the test itself can be 
// performed within a 7EST macro. 
////////////////// 1////1///1 /////I /////////////// 

dtvoid 

i_utg : : t_Semantics ( ) 
I 

T_INIT< •t.Semantics* ) 

//!FIX Add your semantic member function tests here. 



T_CLEANUP; 



///////////////////////////////////////////////// 

// Persistence testing. 

// 

// This tests behavior specific to the persistence 
// member functions of a production class. 
// Between the T.INIT and T.CLEANUP macros the 
// memory manager variable mm is available for 
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// constructing test objects. Each individual 
// test must be surrounded by the T.ST ART and T.END 
// macros, or alternately, tne test itself can be 
// performed within a TEST macro. 

/////////////////y /////////////////////////////// 

dtvoid 

i_utg: :t_Persist () 
i 

T INIT( *t Persist • ) 



//iFIX Add your persistent member function tests here 



T_CLSANUP; 



/////'//////////////////////////////////////////// 
// Return coverage information. 
// 

// NOTE: This is not to be modified by unit 
// test developers. 

///////////////////////////////////////////////// 



dtVoid 

i_utg ; : qryCoverage ( 
dtlnt*t aCovAry, 
dtlnrt aNumFuncs 
> const 

1 

aCovAry = coverage; 
aNumFuncs = TOTAL_FUNCS; 

) 
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///////////////////////////////////////////////// 

// Constructors for class under inspection. 
// 

// NOTE: The following constructors can 

// be modified by unit test developers. 

// The parameters for a given constructor. 

// and the announcement of parameters and 

// resulting objects can be customized 

// by the unit test developer. 

///////////////////////////////////////////////// 




s_utg* 

i_utg: :newlnstance( 

dUJemoryMgr* aMemMgr I 
> * — ' 



33 



3* 



coverage I f _nevlnstancel I ; 
announceMethodStart < •newlnstancel - ); 
s_utg* NevObj = new (aMemMgr) s.utg (aMemMgr) ; 
announceMethodEnd( 'newlnstancel* );, 
return ( NevOb} 



38 
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s__utg* 

i_utg: :nevlnstance( 

dtULong aArgl, 
const dtChar* const a>rg2, 
dttieaoryMgr* aMemMgr ) 



f 



coverage I f_nevlnstance2 ] ; 
announceMethodStart ( a newinstance2* ); 

s_utg- NewObj * new (aMemMgr) s_utg( aArgl, aArg2, aMemMgr ); 
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announceMethodEnd t • newlnstance2 • ) ; 
return ( NewObj ) ; 

) 



i_utg : : newlnstance ( 

dtULong aArgl, 
const dtChar* const aArg2, 
dtlnt aArg3, 
dtWeaoryMgr* aMemMgr ) 



coverage I f_newlnstance3 J ; 
announceHethodStart ( 'newlnstanceS* ); 

s_utg* NewObj s new (aMemMgr) s_utg( aArgl, aArg2, aArg3, aMemMgr ); 
announceMethodEnd ( *newlr.stance3 # ); 
return ( NewObj ) ; 



// JU t //////////////////////// /////////////////// 
// Copy constructor for class under inspection. 
// 

// NOTE: The following copy constructor can be 
// modified by unit test developers. 

/////// // //////// //// ////////////// /// /////////// 

s_utg* 

i_utg: : copy Instance { 
s_utg* alnstance, 
dtMemoryMgr* aMemMgr 



i 



coverage I f_copyInstance] +♦ ; * 
announceHethodStart ( "copylr.stance* >; "Zrj 
s_utg* NewObj = new (aMemMgr) s_utg< • a Instance, axer.Mgr J;-^""" S\ 
announceMethodEnd ( "copylnstance* >; 
return ( NewObj ) ; 



//////////////////////////////////////////////// 

// Destructor fcr class under inspection. 

// 

// NOTE: The following destructor can be 

// modified by unit test developers. 

///////////////////////////////////////////////// 

dtvoid 

i—utgs :deletelnstance{ s_utg* alnstance ) 
I 

coverage I f_deletelnstance ] ; 
announceMethodStart ( 'd eletelnstance* ) ; 
delete alnstance; - 

announceMethodEnd ( •deletelnstance* ); 

) 



///////////////////////////////////////////////// 

// Other member functions. 

// 

// NOTE* The following inspection functions can be 
// modified by unit test developers. 

////////////J//////////////////////////////////// 



s.utgfc 

i_utg: :oper_equal ( 
s_utg* alnstance, 
const s_utgt aRhs 
) 

I 
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coverage I f_oper_equal ) ; 
announceMethodStart* 'oper_equal* ); 
announceParameter* aRhs ); Afs 
aInstance->operator= ( *alnstance ) ; — -n 
announceMethodEnd* •oper_equal # ); 
return ( # alnstance ) ;> 



dtULong 

i^ut g 2 : oper_dtULong ( 
s_utg* alnstance 
> 

I 

coverage I f .oper.dtULong ) ♦ + ; 

announceMethodStart ( •oper_dtULong» ) ; A I 

dtULong testVal = aInstance->operator dtULongO;— ■ — Acjt 
announceMethodEnd* - oper_dtULong' ); 1 
return* testVal ); 

s_utg* 

i_utg: :oper_plusequal ( 
s_utg* alnstance, 
dtlnt aRhs 
) 

\ 

coverage I f_oper_plusequal } ++ ; 
announceMethodStart ( *oper_plusequal • >; 
// announceParameter ( aRhs ); 

aIrstance->operator*= ( *alnstance ); 
announceMethodEnd ( *oper_plusequal • ); 
return ( *alnstance ); 



dtChar 

-_utg : : cper_ index ( 

utg* alnstance, 
dtlnt alndex 
) 

I 

coverage ! f _oper_index I ♦+ ; 
announceMethodStart* *oper_index* ); 
// announceParameter t alndex ); 

dtChar testVal = aInstance->operator ( 1 (alndex) ; 
announceMethodEnd* 'oper_index* i ; 
return* testVal ); 



dtBoolenn 
i^utgi : set ID* 

s_utg* a Instance , 

const dtULong a ID, 

const dtChar* const a Name 

I 

I 

coverage I f_ set ID) ; 

announceMethodStart* # setID - ); • 
// announceParameter* alD ); 
// announceParameter* a Name ); 

dtBoolean testVal * aInstance->s«tID(aID,aName) ; 

announceMethodEnd* •setlD' ); 

return* testVal ); 
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«r Status 

i_utg : : openForRead { 
s_utg*4 aArg. 
dtMemoryMgr* a MM 
I 

C 

coverage 1 f_openForRead )♦♦; 
announceMethodStart ( *openForRead* ); 

erStatus testVal * utg :: openForRead ( (utg*4)aArg, a MM ); 
announceRetVal < testVal ); 
announceMethodEnd ( 'openForRead* ); 
return! testVai ); 

) 



///////.////////////////////////////////////////// 

// Nonclass functions to be tested. 

// 

// NOTE s The following nonclass inspection functions 
// can be modified by unit test developers. 

///////////////////////////////////////////////// 



dzBoolean 
i_utg_export ( 

idtTest* testObj. 

const s_utgi aUtg 

) 



coverage I f _i_utg_export 1 ; 

testObj->announceMethodStart t • i_utg_export • ); 
testObj->announceParameter ( aUtg ); 
dtBoolean testVal = export! aUtg ); 
restObj->announceMethodEnd{ * i_utg_export • ); 
return < testVal ); 



s_utgt 

i_utg_oper_plus ( 

iciTest* testObj, 
const s_ucgt aLhs, 
const s_utgi aRhs 
i 

I 

c overage I f_i_utg.ope r_pl us) 

testobj->announceMethodStart ( • i_utg_oper_plus* ); 
testObj->announceParameter( aLhs ); 
testObj->announc«Parameter t aRhs ); 
s_utg4 testVal a (s.utgfc) operator* ( aLhs, aRhs ); 
testObj->announceMethodEnd( ' i_utg_oper_plus* ); 
return ( testVal ); 

5 
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BASRESC.KH 



/;/////////////////////////////////////////////////////////////////////// 

// FILELNAMEs basresc.hh 
// 

// Copyright 1993 by Marcam Corp., Newton, MA USA 
// 

// This unpublished copyrighted work contains 

// TRADE SECRET information of Marcam Corporation. 

// 

Jl TJse, Transfer, disclosure, or copying without its expressed 

// written permission is strictly forbidden. 

// 

y/////////////////////////////////////////////// ////// ////////////////// 

*i IndeX basrescHK 
« define fcasrescHH 

♦include •geninst.hh* // For fdGenlnst 

♦include •bcdatet.hh* // For bcDateTime 

♦ include •nameulchh - // For fdNameUK 

♦include •dtbitv.hh* // For dtBitVector (dummy) 

class EEPORT BasicResource; 

♦ifdef OSEJTEMPLATES 

•include •orb.hh* 
**ndif 

*i;«rl%f SCHENIACOMPILER 
«mciu<j« •basresc.h - 
♦endif 

///////////////////////////////////////////////////////////////////////// 
// !CLASS_DECL_S 
// : LIBRARY 

// ! NAME BasicResource 
// .'TEXT 

// BasicRecource is the implementation of a generic instar.ce-der ived 

// class. This is an independently persistable kind (I?K>. 

// 

J I The user's access rights will be checked whenever f dSecur ityContext 
// appears as a parameter. I! the us*r does not have appropriate acce*3 
// ;n th** standard UI/App API, an error message will be returned. 
// 

// A returned pointer to an erMsg or eiMsgList indicates an error 
// occurred. A NULL pointer indicates successful completion of 
// the member function. 
// 

// ! AUTHOR <Author*s name> <(Author*s E-mail address)> 

// J REVIEWER <Revi ewer's name> <tReviewer's E-mail address)> 
// i REVIEW JATE <dat«> 
// 

y//////////////////// //////////////// /////// ///////////////// /////////// 



class EXPORT BasicResource : public fdGenlnst 
publics 

///////////////////////////////////////////////// 
// !METHOD_DECL.S 
// 3 NAME close 
// !TEXT 

// This static method closes the current object, 
// releasing all database and memory resources. 
// When successful, the aBasicResource pointer 
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// is set to Null. 
// 

// **Standard UI/App API , implemented in stdgi.cc** 

/////✓/////////////////////////////////////////// 

static erMsg* close { BasicResource*^ aBasicResource, 
dbTransCtx*4 aDbCtx ); 

///////////////////////////////////////////////// 
// !METHOD_DECL_S 
// 1KAHE create 
// !TEXT 

// This static method creates a new BasicResource, 
// which is returned in aBasicResource. A Null 
// pointer is returned if the object could not be 
// created, along with an error message. 
// 

// —Standard UI/App API, implemented in stdgi.cc** 

y//////////////////////////////////////////////// 

static erMsg* create ( BasicResource** aBasicResource* 

dbTransCtx*4 aDbCtx, 

fdSecurityContext aSecurityCtx, 

fdlnstTypes: : type aType, 

dtMemoryMgr* a MM ) ; 

/////////////////////////////////////////,/////// 
J i !METKOD_DECL S 
// \ NAME create" 
// iTEXT 

// This static method creates a BasicResource from 

// another existing instance. This is analogous 

// to a copy constructor . A Null pointer :s returned 

//if the object could not be created, aiong with 

//an error message. 

// 

// ••Standard UI/App API , implemented in stdgi.cc** 

//////////////////////////////////////// ///////// 

static erMsg* create* BasicResource** aNewBasicResource. 

const BasicResource* aOldBasicResource! 
dbTransCtx** aDbCtx, 
fdSecurityContext aSecurityCtx, 
fdlnstTypes: : type aType. 
dtMemoryMgr* a KM ) ; 

/////////////////////// /////// /////////////////// 

/ / ! METHOD_D£CL_S 

// sname openforChange 

// iTEXT 

✓/ This static method retrieves an existing BasicResource 
// 2T. . ! databas « b y its user key so that it can be 
// modined. If an error occurs the aBasicResource 
// pointer will be set to Null, and an error message 

static erMsg* openForChange < BasicRMfiiir^t^tBasicRe source, 

consp^TdNaroeu*fct aBasicResourceUK, 
dbTranSCr*** — aDbCtx. 
fdSecurityContext aSecurityCtx, 
fdlnstTypes:: type aType, 
dtMemoryMgr* a MM ) ; 
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///////////////////////////////////////////////// 

// !METHOD_DECL_S 

// !NAME openforReview 

// !TEXT 

// This static method retrieves an existing BasicResource 

// from the database by its user Key in a nonmodif iable 

// mode. If an error occurs the aBasicResource 

// pointer will be set to Null, and an error message 

// is returned. 

// 

// ••Standard Ul/App API, implemented in stdgi.cc** 

y////y/////////////////////////////////////////// 

static erMsg* openForReview( Basic Resource*4 aBasicResource, 

const^ gNameUK^ ^ ^asicResourceUK, 
dbTrans'ClX'L i. "-.x, 

fdsecuritycontext ase_. .tyctx, 
fdlnstTypes: :type aType, 
dtMeraoryMgr* a KM ) ; 



\ 



///////////////////////////////////////////////// 
// !METHOD_DECL_S 
// "NAME remove 
// !TEXT 

// This static method removes an existing BasicRe?;:. * 
// from the database. When successful, the 
// aBasicResource pointer is Null (the object has Deer. 
// deleted from memory) . If an error occurs, e.g., 
// validateToRenove < > fails, then an error message 
// is returned. 
// 

// '^Standard UI/App API, implemented in stdgi.cc** 

///////////////////////////////////////////////// 

static erMsgList* remove* BasicResource** aBasicResource. 

dbTransCtx** aDbCtx, 
f dSecurityContext aSecurityCtx J ; 

'.*/// *'///////////////////////////////////////// , 
' i.v :d_decl_s / 

' !! 3aveAs / 

static method saves the current object as a new 
// object using the supplied user key and type. The / 
// original object (aOrigBasicResource) is closed, 
// and the new object (aNewBasicResource) is saved 
// to the database and remains in memory. Validation, 
// errors during save are reported. 
// 

// ••Standard UI/App API, implemented in stdgi.c* 

y//y//////////////////////////////////////////>f/ 

static erMsgLisf saveAs< BasicRe^nnrrat^XaNewBasicResource, 

const (JdNameJJKj aBasicResourceUK, 
BasicReS&UVfie"*i aOrigBasicResource, 
dbTransCtx** aDbCtx, 
fdsecuritycontext aSecurityCtx, 
fdlnstTypes :: type aType, 
dtMemoryMgr* a MM ) ; 

///////////////////////////////////////////////// 
// !METHOD_DECL_S 
// !NAME validateToRemove 
// !TEXT 

// This virtual method (declared pure virtual by fdGenlnst) 
// performs all validation (referential integrity) 
// repaired before removing this object from the database. 
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class EXPORT i_BasicResource : public idtTest 
< 

public: 

umimmummuuiuuimmummum 

J I Inspection class constructor. 

//////uuuuuuuuuuuuuuuuuuuuui 

IJBasicResource ( 

dtStreamExecutive* aStreamExec, 

dtMemoryExecutivei aMemExec, 

idtTestArgs* aTestArgs, 

dtMeaoryMgr* aTestMM ); 

iuumummmmummuumuumum 

// inspection class destructor. 

umiimiuuuumunuuuumuuuuim 

-i^BasicResourc* ( ) ; 

inummmmmmmiuiumttummim 

// Inspection test suite. 

jn/uuuimuuiiuiuuumumuuuium 

virtual dtvoid t_LifeCycle< ) ; 
virtual dtvoid t_Operators ( > ; 
virtual dtvoid t_Semant ics i) ; 
virtual dtVoid t_SetQrys(); 
virtual dtVoid t_Persistl); 
virtual dtVoid qryCoverage ( dtlnft aCovAr v^ citlr.ti aNunFuncs ) cons: 

void setupUKs ( 





dzVcid -^"p^i if* ^e^aoe^irgeb alnstance. 

dtMemoryMgr* aKM ); 

^umuummmumummummumum 

II Member function close. 

H 1 1 II U 1 1 U I U II U II I II 1 1 U II II II II 1 1 1 I 1 1 II i I I / / 
«>:sg* closet s_BasicResource*& aBasicRescurce. 

dbTransCtx^i aCbCtx ); 
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///////////////////////////////////////////////// 
// Persistence testing. 
// 

// This tests behavior specific to the persistence 
// member functions of a production class. 
// 

// Between the T_INIT and T_CLEANUP macros the 
// memory manager variable mm is available for 
// constructing test cbjects. Each individual 
// test must be surrounded by the T£ST_START and TEST.END 
// macros, cr alternately, the test itself can be 
// performed within a TEST macro. 
///✓///////////////////////////////////////////// 

dtVoia 

i_Ba si cRe source : : t_Pers ist ( ) 
{ 

// STDGIT.TESTCtASS and STDCIT_OEJREF must be establj 

// ^ ^ 

* define £7 DC IT_T £ STCLA S S Cs_ Ba s i c R e_so u r c £ 
^define STDGIT_GBCREF ^^OoTneT 

// At least one ~t" the following must be present. 
// 

♦define STD3I7_PR0DUCTI0N 
S — -\ //^define STDGIT.wjp 

//♦(define S7DG I7_7EMPLATE 

y/ftdefine stog:7_ixpcr?_e:<pok: 

:NIT( T._Persisf } 

ST\ fTaNaroeUX \uKl ( mm ) ; 

( ) } fdNameUK Vjk2 ( mm ) 

jj dNr.v.etJX > jk3 ( mm ) , 

^TT - :t_?.:stclass- obji = jstdgitjtestclass* » null .* 

^t:-_;7_7lstclass' cty^ = < stdgi7_je::: class* » null; 

S7DGT7_?ES7CLAS3* cbj J = { S7DGI7_7ES7CLAS3 * ) NULL; 
fP\ ///!FIX You may need to specify a security zor.z&xi . 
\)J f f dSecurityCcntext security = FD_SC_NC_cc;c7EX? ; 
\SS I //iFix when implemented b v_ grr^TT.CC th e r^^f rpcui r*>ri 

1_//!f; 



fcKindRef< oOb j He f - s i c Res cur cg > ( ^t£: '• a neU> > > kr; 
// Setup the user keys for the 3 \^>^:5c:s. 
setupUKs( ufcl. uV.T, uk3, mm ), 




r 



// Standard test for fdGer.Inst derived classes. 
// Runs through normal persistent lifecycle for 
// production instances. 
// 

^include •stdgit.cc" 
T_CLEANUP 



> 



///////////////////////////////////////////////// 

// Return covere»>- information. 

// 

// NOTE: This is not to be modified by unit 
// test developers. 

///////////////////////////////////////////////// 
dtvoid 

i_BasicRescurce: :qryC;verage { 
dtlnffc aCovAry, 
dtlntt aNumFuncs 
) const 

aCovAry = coverage; 
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I_BASRES.CC 



9 




alJ'JSPuncs = TCTAL_,FUNC S ; 

) 

7///////////////////////////////////////////////. 

?/setupUKs: 
// 

// Helper function for persistence testing. 
// ret up three user keys for the three 
// objects used during the STDGIT. 

/// /////////////// uuutmnj^iti //////////// 
dtvoia 

fdNajneUK*>| aUKi, 
fdNameUKi/ aUK2, 
dN ajneU& r aUK3 # 
dtMemoryMgr* a MM 
) 



i 



// Remember -axiir.'.un string lengths when setting up test 

// object names and site names. Names are usually 

// a jnaximun of IS characters, sites are 4 characters ir.a 

// 

bcStringilSn nantel ( (dtUChar*) 'Test Object 111*, aKM) 
bcStringiI8n name2 ( (dtUChar*) 'Test Object 222 *, aKM) 
bcStrinqilGn naa»e3 ( (dtUChar*) 'Test Object 333 ', a MM ) 
bcStringilBn suel( {dtUChar- j 'Sill*, a KM) 
bcStrir.gilSn site2< (dtUChar* i 'S222', a MM ) 
bcCLringilBn sitei ( {dtUChar*} 'S333', aMM) 



// !FTX 

y/iFi): 



Set up 3 user Keys, 
scoped user key ifrc 



Tp€ rci*owm? v 
;m SNUK skeleton) 



or; 



> fcr 
four 



a c-ari 
U K r. a v 



neec r.cre. 



r/^l.setNar.e ( namel ); 
aUKl-setSiteNanie ( sital ); 

aU.K2 .sstName t name2 }; 
aU!'.2 . set £i cieName ( site2 ); 



aUK3 . setName ( nane3 ); 
aUK3 .setSi teName ( site3 



/^7// ///////////// //////// ///;/////////; //////*/ 

// setupObj: 
// 

/ / Helper function for persistence testing. 
// Set the attributes in the passed object 
//so that it is valid and can be saved. 

/////////////////////////////////// ///^. 



6 



dtvoid 

l_Ba sicResourcet :s 
<^_nasiCKesourc^ 
Q lH^oryMSr 1 ''" 
) 




tfpobj ( 
alnstance, 
-MM 




/////// 



N Descriptions have 
// 

bcStringilBn descrl ( 
b=Stringil8n descr2 ( 
bcScringilSn secGrp( 



a naxinuiu length ot IS. 

(dtUChar*) 'Description 111", a MM) 

(dtUChar') 'Descripticn 222*, a MM) 

(dtUChar*) 'Securitv croupX*, a KM) 



alnstance->setDescriptioni ( tdescrl ); 
aInstance->setDescrlption2 ( &descr2 i ; 
a!nstance->setSecurityGroup( tsecCrp ) j 



//!FIX >» Add addtional setup here. 
3 
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// Test 1: First Constructor & Destructor 
// 

// Set up test w 

TLIFE_STAJlT( -ctorl and Otor* ] — "~ Memory manager m set up, scope csubli shed 

(D^^ // First, run the constructor, then dump the object, then delete :t 

s -* rMs 3* fcssl - newinstancet fdyscTest. ETKy SCTEST^NAHE . EF.MSGTEST_1 . FIL E LIN r 

announceObJect ( *mscl ); e, a*-a n 

@ deleteJnstancei msgl >; Standard «rM* a Parameters 

// Complete Llfecycle test... 
TLIFE.ZND Scope ended. Memory manager checked for leaks 
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// Test 1: qryMfigID 

// 

s_*rnsg» msgl * newinscance t :dMsgT«st3, ERKSCTEST_N*XE. EFJHSC7EST.3 . 
TESTt "qrvMsglD*. fdMsgTtsta =* qryMsgio< msgl > ) 
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Pfism/OT Inspection Harnett 
C:\PRJSMOT\TEST 

Inspection DLL: 



Destination File: 



dtordrei.dll 




§ Browse 1 


CAPR!SMOTAFD\UNfTTEST\U7\EXE\W!N 


dtordrel.out 
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